去年 Vibe Coding 突飞猛进，AI 编程已经逐渐普及。 很多团队对于写代码这件事的定义开始有一些变化。变化在于产出代码的方式：越来越多的代码来自模型，程序员更多时间花在和模型聊天，把问题说清楚、把边界卡住、把结果验明正身。

我愿意称之为「程序指导员」。写代码仍然在发生，但我们的动作从「逐行敲」转到「聊天与校验」。

1. 程序指导员在做什么

把一段需求交给 AI，得到一段能跑的代码，然后多聊几句，一个功能就完成了。但是这个功能是不是可维护、可上线、可回滚、可观测、可审计，就不太确定了。

程序指导员的核心工作通常包括这几件事：

1. 把需求翻译成可执行的任务 需求里混着业务语言、边界条件、历史包袱、隐含约束。模型的信息中这些可能是缺失的。我们要先做一次结构化翻译：输入是什么、输出是什么、失败怎么处理、性能底线是什么、兼容范围是什么。
2. 把任务拆成模型能稳定完成的块 一次性让模型写完一个完整功能，也可以，让 CC 多跑一段时间，但成功率不稳定。更稳的方式是拆成小块：数据结构、接口定义、核心逻辑、错误处理、测试、文档、迁移脚本，各自生成、各自验证，然后再组装。这种方式让我们更有掌控力，知道发生了什么，过程可控。
3. 给足约束，减少「自由发挥」空间 约束要可检验：必须用现有依赖、必须兼容某版本、必须遵守公司日志规范、必须不新增公网访问、必须在某条 SLA 内、必须覆盖某些用例。
4. 验收与兜底 模型会给出看起来合理的实现，也会在边界上“编”。程序指导员要像做 code review + 测试负责人那样工作：读关键代码、跑测试、补测试、压测、看日志、看回归风险、看安全风险。最后要能回答一句话：这段代码出问题，谁来修、怎么定位、怎么回滚。

这套工作方式和当前的 CC 一把梭相比，并不先进，甚至有些落后。

和以前相比，以前也有模板代码、脚手架、复制粘贴、搜索引擎。不同点在于：AI 把「生成」能力推到台前，生成速度极快，错误也更隐蔽，导致「指导与验证」的权重被迫上升。

2. 变了什么

2.1 输入从「代码」变成「任务说明书」

以前的输入主要是我们写的代码和我们改的代码。现在多了一种主要输入：我们写给模型的任务说明书。

这份说明书的质量，直接决定产出质量。写得好，模型像一个执行力强的中级工程师；写得差，模型像一个自信的实习生。

说明书里最重要的内容通常包括：

• 目标：要解决什么问题，做到什么程度算完成
• 环境：语言版本、框架版本、已有目录结构、现有依赖、运行方式（一般在规则上下文中给出）
• 接口：入参、出参、错误码、异常策略、幂等、重试、超时
• 约束：性能、资源、兼容、安全、合规、日志、监控
• 验收：必须通过哪些测试，用哪些样例验证，输出应满足哪些断言

把这些写清楚，能把 80% 的返工挡在模型生成之前。

2.2 工作节奏从「连续编码」变成「短回路迭代」

传统编码经常是长回路：写一段、跑一遍、再改。AI 编程的高效来自短回路：AI 生成完成，自动编译构建，自行测试，然后马上验收，发现偏差、立刻补约束再生成。

短回路的关键在于每一轮都要带着明确的失败信息回去：哪条测试挂了、哪个接口不对、哪个边界漏了、哪个依赖版本冲突。模型对这种「可定位的反馈」反应更稳定。

2.3 代码量不再是效率指标

代码生成变快之后，代码量会失真。以前一个人一天写 500 行算多，现在模型十秒能吐 500 行，一天几千行可用的代码随随便便。

更有意义的度量指标会转向：

• 需求到可用版本的周期
• 线上缺陷率与回滚率
• 变更影响范围（改动越小越好）
• 可维护性（复杂度、重复度、依赖扩散）
• 测试覆盖与回归效率

如果团队还用「写了多少行」「提了多少 PR」来衡量，会很快走偏：大家都能刷产出，系统质量却下降。

2.4 「看懂代码」变得更重要

模型写的代码往往「像那么回事」，也可能更长、更绕、更喜欢堆抽象。程序指导员必须能快速识别几类问题：

• 关键路径上不必要的复杂度
• 隐性性能问题（多余的拷贝、无界缓存、低效循环）
• 错误处理缺失（吞异常、错误码混乱、重试风暴）
• 并发与资源泄漏（锁、连接、文件句柄）
• 安全问题（注入、越权、敏感信息日志、依赖风险）
• 与现有系统契约不一致（字段含义、时序、幂等等）

以前也需要这些能力，但当代码产出速度暴涨时，「看懂与筛掉问题」的能力会直接决定我们能不能把速度兑现成质量。

对了。顺嘴提一句，技术大厂，前后端-测试机会，全国一线及双线城市均有 坑位，待遇和稳定性还不错，感兴趣看看。

3. 没变什么

变化再大，有些东西一直没变，而且变得更值钱。

3.1 对业务的理解仍然是门槛

模型可以补全语法、补齐样板、生成测试，但它很难替我们承担「业务正确性」。尤其在边界条件、例外流程、历史债务、灰度策略上，错误经常不是编译错误，而是业务事故。

谁最懂业务，谁最知道「哪些地方不能动」「哪些数据不能算错」「哪些流程不能重试」，谁就更能驾驭 AI 编程。

换一个大家更常用的词语，就是领域知识要在线，否则错了你也不知道错了。

3.2 系统设计能力仍然决定上限

模型擅长在给定结构里填充实现，不擅长从零做合理设计。系统边界怎么划、数据怎么流、接口怎么稳、状态怎么管理、失败怎么收敛、观测怎么做，这些决定了系统能不能长久演进。

如果把“设计”也交出去，模型会给一个看似完整的方案，但常见问题是：

• 组件拆得漂亮，运行链路混乱
• 过度抽象，改一处牵一片
• 忽略现有基建与规范
• 缺少可观测与运维视角

当然，这些问题都可以通过提示词来解决，不过对于系统设计的认知还是需要我们来把握，至少我们得知道什么是好什么是坏。

系统设计这件事，仍然需要人来负责，并且要更早介入。

3.3 责任边界没有变化

代码是模型生成的，并不改变责任归属。线上出了事故，审计追责、复盘改进、长期治理，仍然落在团队身上。

在群里看到一个消息，最近有一个团队 AI 生成的导致线上数据全部被覆盖，团队绩效今年基本和他们没有关系了。

所以「让模型写」不是免责理由，反而要求流程更严：评审、测试、灰度、回滚、监控、告警、应急预案，一个都不能少。

4. 程序指导员需要哪些基础认知

4.1 对模型能力边界的认知

模型的强项：

• 快速生成代码、接口定义、CRUD、数据转换
• 根据已有代码风格补齐实现
• 生成测试用例框架、mock、基础断言
• 把自然语言需求翻译成「看起来像」工程方案

模型的弱项：

• 对真实业务语义的可靠理解（尤其隐含规则，，因为其没有上下文，甚至有些隐含规则我们自己也没有意识到）
• 对运行时约束的自发遵守（性能、资源、稳定性）
• 对项目历史约定、隐性依赖的自动继承
• 对安全与合规的默认正确
• 对「细微但关键」的一致性（字段含义、状态机、时序）

程序指导员要把弱项当成默认风险。

4.2 任务拆解能力

拆解不是把大需求拆成很多小需求就结束了，而是拆成“可验证”的单元。

可验证的含义是： 每一块都能用编译、单测、静态检查、契约测试、跑一段 demo 来确认对不对。

拆解时常见的顺序：

1. 先定接口与数据结构（契约优先）
2. 再做核心逻辑（关键路径先跑通）
3. 补错误处理与边界（把失败收敛）
4. 加测试与观测（让后续修改可控）
5. 最后做重构与清理（收敛复杂度）

这个顺序能减少返工，也更适合把生成结果分段纳入工程体系。

4.3 约束表达能力

约束要写成「可执行」的规则。

常见可执行约束：

• 依赖：禁止新增依赖；必须使用项目已有库
• 版本：必须兼容某版本运行环境
• 性能：某接口在某数据量下耗时上限
• 幂等：重复请求的处理方式
• 日志：必须打哪些字段；禁止打印哪些字段
• 错误：错误码范围；异常抛出策略；重试策略
• 兼容：老接口字段不可删；新增字段默认值策略
• 安全：输入校验、权限校验、敏感信息处理

当我们把这些写清楚，模型就可以更规范的交付了。

4.4 验证习惯与测试能力

验证还是要靠工程化手段。

最低配置的验证链路：

• 静态检查：lint、类型检查、依赖扫描
• 单元测试：关键逻辑与边界条件必须有断言
• 集成测试：接口契约与关键链路
• 回归策略：哪些模块必须跑全量，哪些可抽样
• 观测：日志、指标、链路追踪的基本补齐
• 灰度与回滚：发布策略与开关方案

把这些链路搭好，AI 才能变成稳定的生产力工具。否则它更像一个加速出错的发动机。

5. 小结

程序员变成程序指导员，不是职位变了，是工作重心变了：写代码的时间变少，把问题讲清楚、把系统守住、把风险挡住的时间变多。

最近阿里出来的 P10 毕玄，在其创办的公司贝联珠贯中宣布不再按传统的专业分工，所有的人都叫 Agent 全栈工程师。

我想象中的团队也是这样，通过合并工种，减少沟通，让 AI 发挥出更大的价值。

在做这些之前，我们需要问一下自己三个问题：

• 我们的验收标准有没有变得更清晰
• 我们的测试与观测有没有跟上生成速度
• 我们有没有把隐含知识变成显性规则

答案越清楚，AI 带来的就越接近真实效率。否则只是把编码速度提上去，把返工和事故也一起提上去。

以上。

——转载自：潘锦