AI 编程从生成代码变成远程协作

AI 编程正在越过一个分界线。

早一点的时候，我对 AI 编程的理解还很简单：它是一个更聪明的补全器，可以帮我写函数、改样式、解释报错、生成测试。这个阶段的核心动作是“问它”，人的注意力仍然紧贴着编辑器，AI 只是局部加速。

现在更有意思的变化是：AI 开始变成一个可以接任务的开发协作者。它能读仓库、跑命令、改文件、启动服务、看浏览器、修测试，甚至在我离开电脑的时候继续推进一段明确的工作。

这件事的关键不在于“模型会不会写代码”。更关键的问题是：一个真实工程项目，能不能承受这种新的协作方式。

从补全器到远程协作

补全器解决的是局部问题：这个函数怎么写，这段 CSS 怎么调，这个类型错误怎么改。它的反馈周期很短，人的判断也很近。

远程协作解决的是流程问题：这个页面能不能做完，这个 bug 能不能定位，这个 PR 能不能清理到可合并状态。它的反馈周期更长，中间会发生很多选择。

这两者需要的能力不一样。

补全器
  -> 看当前文件
  -> 生成一段代码
  -> 人立即检查
 
协作者
  -> 读项目结构
  -> 建立任务边界
  -> 修改多个文件
  -> 自己验证
  -> 汇报风险和结果

前者考验模型的语言能力，后者考验系统的工程能力。真正的难点不是让 AI 写出一段看起来像代码的文本，而是让它在一个有历史、有约束、有用户、有部署风险的项目里做出正确的改动。

委派任务之前，先定义完成状态

我现在越来越少给 AI 一个开放式指令，比如“帮我优化一下”。这种指令看起来省事，实际会把判断压力留到最后：它可能改了很多东西，但我不知道哪些改动真的重要。

更有效的做法是把任务写成可验收的状态：

• 这个 bug 在什么路径复现。
• 正确行为是什么。
• 哪些文件可能相关。
• 哪些行为不能破坏。
• 最后必须跑哪些检查。

这不是为了把 AI 管得更死，而是为了减少它在错误方向上消耗上下文。

相反，我不太愿意把“决定产品方向”“重构核心架构”“选择商业化策略”这类任务直接丢出去。AI 可以参与分析，但最终判断必须回到人手里。

手机不是用来写代码的，是用来保持控制权的

当开发工具开始进入移动端，表面上看像是在回答一个问题：能不能在手机上写代码？

我觉得这个问题问错了。手机不适合长时间写代码，也不适合处理复杂 diff。它真正适合的是另一类动作：

• 看任务进度。
• 读关键结论。
• 批准或拒绝下一步。
• 补充约束。
• 在排队、通勤、离开工位时中断错误方向。

这意味着 AI 开发的交互重心会从“我坐在编辑器前连续操作”变成“我在不同场景里持续管理一个任务”。

电脑仍然是主战场，但手机会变成控制面板。它不负责承载全部工程细节，而是负责让人不失去决策权。

这对产品设计有直接影响：移动端不应该复刻桌面 IDE。它应该优先展示任务状态、关键 diff、失败原因、验证结果和下一步选择。

真正重要的是工作流，而不是某一次生成

AI 写出一段代码并不难。难的是它写完之后发生什么。

在真实项目里，我更关心这些问题：

1. 它有没有先读现有代码，而不是凭空发明架构。
2. 它有没有把改动限制在任务边界内。
3. 它有没有跑必要的检查。
4. 它有没有说明没有验证的部分。
5. 它有没有保留可审查的 diff。
6. 它有没有在遇到不确定性时收窄问题，而不是继续扩大修改面。

这些问题决定了 AI 能不能进入长期开发流程。

如果一个工具只能生成代码，但不能可靠地解释它改了什么、为什么改、怎么验证，那它仍然只是一个更快的片段生产器。片段生产器会提高局部速度，但也可能增加整体维护成本。

我真正想要的是一个能进入工程闭环的协作者：

理解任务
  -> 探索代码
  -> 做最小改动
  -> 运行验证
  -> 暴露剩余风险
  -> 等待人类决策

这里面最重要的词不是“自动”，而是“闭环”。

人的价值会往上移，但不会消失

AI 参与越深，人越不能只做代码录入员。

以前工程师的大量时间花在把意图翻译成代码。现在这部分会被压缩，人的注意力会更多转向几个更高层的问题：

• 这个需求是否值得做。
• 这个抽象是否过早。
• 这个实现是否符合产品真实使用场景。
• 这个系统出了问题时能不能定位。
• 这个改动未来半年会不会变成负担。

这些判断不只来自技术知识，也来自对用户、产品节奏、团队能力和系统历史的理解。

所以我不认为 AI 编程会让工程判断变得不重要。相反，它会更快地暴露判断质量。因为生成速度越快，错误方向造成的浪费也越快。

我自己的工作台会怎么变化

我理想中的个人开发工作台，不是一个聊天框，也不是一个按钮很多的 IDE 插件，而是一组连续的工程界面：

• 本地仓库负责承载真实代码。
• 终端负责执行构建、测试、脚本和部署命令。
• 浏览器负责验证产品行为。
• 文档和记忆系统负责保存长期上下文。
• 手机负责在离开电脑时查看状态和做高层决策。
• AI agent 负责在这些界面之间执行明确任务。

人的角色不是消失在流程里，而是站在流程上方，持续做取舍。

这也是我为什么越来越关心“个人工作台”这个概念。单个工具会变化，模型能力会变化，平台入口也会变化。但一个可靠的工作台应该把这些变化吸收掉，留下稳定的工程习惯。

我现在会给 AI 的几条规则

如果把这段时间的使用经验压缩成规则，大概是这几条：

1. 先让它读代码，再让它改代码。
2. 任务要小到能验证，大到值得委派。
3. 每次改动都必须留下可读 diff。
4. 不要让它用“重构”包装不必要的扩大修改。
5. 让它主动说明没跑过什么验证。
6. 把产品判断、风险判断和发布判断留在人手里。

这些规则看起来保守，但它们能让 AI 进入长期工程，而不是只在 demo 里显得聪明。

收尾

AI 编程的下一阶段，不是“谁能生成更多代码”，而是“谁能把 AI 放进真实工作流，并且仍然保持工程质量”。

这件事最终会改变开发者的日常动作。我们会少敲一些样板代码，多写一些验收标准；少盯着每一行实现，多看系统边界和产品结果；少把工具当作单次回答，多把它当成一个需要管理的协作过程。

我不觉得这会让工程变得轻松。它会让工程变得更快，也更暴露。

暴露问题本身不是坏事。真正有价值的工作流，应该让错误更早出现，让判断更清楚，让人有更多精力处理那些仍然必须由人负责的问题。