成熟系统里使用 AI：先定边界，再让它写

AI 适合读代码、整理调用关系、补类型、写测试和缩小问题范围。把它放进一个已经运行的系统时，风险通常不在“它写得快”，而在它会顺着局部代码把边界一起发明出来。

人要先划定什么能共用

开始生成之前，规则里就应该写清：

• 哪些组件可以复用，哪些差异必须留在页面
• 请求从哪一层发出，错误怎么提示
• 新文件放在哪个目录
• 一种交互有哪几种状态

这些决定如果留给生成过程，同一条业务会出现多套写法。代码能跑，后续的修改却会互相冲突。抽象范围是设计决定，不是生成时的副作用。

大需求要拆到可以核对的程度

成熟系统里一次生成整块功能，结果很容易变成黑箱。上线前至少要单独核对：

• 拆开的需求是否覆盖原来的场景
• 页面和操作是否都有对应实现
• 空数据、失败、重复提交这些边界放在哪里
• 新结构有没有改写已有数据的含义

调用链可以让 AI 先读出来，再由人确认哪些函数是入口、哪些字段不能变。类型和提交文档也适合它起草，但草稿要能被现有实现核对，而不是只看生成代码自身是否自洽。

测试、诊断和读系统，同样是它能做的工作。只有写代码这一项时，黑箱会更大。

MCP 扩大的是工具，不是权限

外部系统提供 MCP server，把自己的 API 收成工具后，Agent 可以在对话里查询或执行这些工具。这是间接调用一块已声明的能力，不是获得那个系统的全部控制权。

工具列表就是边界。没有暴露的操作，不应该靠让模型“想办法操作界面”去补。

流程可以让它汇总，结论要人收口

例如收集分支、提交和变动范围，整理成一份提测说明，是适合交给它的汇总工作。它不应该同时决定这次改动的抽象是否合理、影响面是否被接受。汇总是材料，收口仍然是人的判断。