当 AI 写代码：Copilot 之后的变化
git diff 只剩 12 行时，变化已经很具体：写代码的时间，可能开始少于审查 AI 生成结果的时间。
Copilot 刚出现时，最明显的变化是补全变长了。以前是补一个变量名、一个函数调用；后来变成一整个循环、一段测试、一份接口封装。那时讨论重点还是“它准不准”。现在的问题更实际：不是 AI 能不能写，而是人还要不要按原来的方式写。
补全之后，真正变化的是节奏
Copilot 早期更像快一点的输入法。你敲几下，它猜后半句。这个阶段容易理解，也容易接受，因为工作流没变：人主写，AI 补尾巴。
后来的变化更明显。现在很多 AI 编程工具会同时处理过去分散的几个动作：
读上下文
读取当前文件、相关函数、报错信息，推测你在改什么。生成初稿
不只补一行，而是先给出一版可运行的结构。解释和修补
你继续追问“为什么这样写”“有没有边界问题”，它再迭代修改。
这会把编程从“逐行输入”推到“先审稿，再动手”。更直接的变化不是效率口号，而是注意力位置变了：键盘敲得少了，判断做得更多了。
更稳的场景，不是整包交付，而是小块闭环
AI 辅助写代码更适合“小块闭环”任务：输入清楚，输出容易验证。
例如：
数据格式转换
像 JSON 转 CSV、日志字段提取、时间格式归一化。这类需求规则明确，结果也容易核对。
重复样板代码
例如接口请求封装、表单校验、配置映射、分页查询。人不想反复写，AI 适合先搭底子。
测试用例骨架
给一个函数，让 AI 先列出正常输入、空值、异常值几类情况。断言通常仍需人工检查，但比从空白开始更省力。
报错定位的第一步
把报错栈、相关代码片段、预期行为交给它，让它先给出排查方向。这里更适合把它当作“排查建议”，不是直接采纳修复方案。
这些任务有个共同点：结果容易验。代码能不能跑、测试能不能过、输出是否一致，都能较快确认。
最容易被高估的，是“懂你的项目”
AI 写代码的限制，往往不在语法，而在“局部聪明，全局短视”。它可能会写一个函数，却未必知道这个函数会不会破坏旧接口；也可能补出一个看起来完整的类，但没有真正理解项目里的命名习惯、异常处理和权限边界。
最常见的误判是：生成结果“像那么回事”，就被当成“已经理解项目”。这两件事不是一回事。
一个实用的判断方式是看它能不能回答这三个问题：
- 这段代码依赖了项目里的哪些约定？
- 如果改这里，最可能影响哪个旧逻辑？
- 这份实现里，哪些地方其实是猜的？
如果答不出来，或者答得很空，就不该把它当成已经理解了全局。
Copilot 之后，提示词没那么重要了，约束更重要
很多讨论还停留在“怎么写 prompt”。这当然有用，但在代码场景里，更关键的通常不是措辞，而是约束。
与其说“帮我优化这段代码”，不如直接给边界：
- 不改函数签名
- 保留现有返回结构
- 只处理空值和异常分支
- 输出 diff，而不是重写整个文件
- 先解释风险，再给修改版
这些约束的作用很直接：减少自由发挥。AI 一旦开始“发挥”，小修很容易变大改。
更合适的分工通常是：
- 人定义边界、验收结果、承担后果
- AI 起草、补全、对照、给建议
变化不只是“让 AI 生成代码”，而是“让 AI 在护栏里生成”。
更值得养成的两个习惯
先让它说，再让它写
先问它准备怎么改、为什么这么改、可能影响什么。解释先过一遍，再出代码，更容易发现它是不是理解错了。
永远保留可回退点
不管是 Git 提交、临时分支，还是单文件对比，都要让“撤销”足够简单。AI 辅助最麻烦的不是写错，而是一次改太多，最后难以定位问题。
接下来更值得观察的，可能不是它还能多写多少代码，而是它什么时候能更稳定地说明：这段代码为什么要这样写。