去年 Vibe Coding 突飞猛进，AI 编程已经逐渐普及。 很多团队对于写代码这件事的定义开始有一些变化。变化在于产出代码的方式：越来越多的代码来自模型，程序员更多时间花在和模型聊天，把问题说清楚、把边界卡住、把结果验明正身。
我愿意称之为「程序指导员」。写代码仍然在发生，但我们的动作从「逐行敲」转到「聊天与校验」。
1. 程序指导员在做什么
把一段需求交给 AI，得到一段能跑的代码，然后多聊几句，一个功能就完成了。但是这个功能是不是可维护、可上线、可回滚、可观测、可审计，就不太确定了。
程序指导员的核心工作通常包括这几件事：
-
把需求翻译成可执行的任务
需求里混着业务语言、边界条件、历史包袱、隐含约束。模型的信息中这些可能是缺失的。我们要先做一次结构化翻译：输入是什么、输出是什么、失败怎么处理、性能底线是什么、兼容范围是什么。 -
把任务拆成模型能稳定完成的块
一次性让模型写完一个完整功能，也可以，让 CC 多跑一段时间，但成功率不稳定。更稳的方式是拆成小块：数据结构、接口定义、核心逻辑、错误处理、测试、文档、迁移脚本，各自生成、各自验证，然后再组装。这种方式让我们更有掌控力，知道发生了什么，过程可控。 -
给足约束，减少「自由发挥」空间
约束要可检验：必须用现有依赖、必须兼容某版本、必须遵守公司日志规范、必须不新增公网访问、必须在某条 SLA 内、必须覆盖某些用例。 -
验收与兜底
模型会给出看起来合理的实现，也会在边界上“编”。程序指导员要像做 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 来确认对不对。
拆解时常见的顺序：
-
先定接口与数据结构（契约优先） -
再做核心逻辑（关键路径先跑通） -
补错误处理与边界（把失败收敛） -
加测试与观测（让后续修改可控） -
最后做重构与清理（收敛复杂度）
这个顺序能减少返工，也更适合把生成结果分段纳入工程体系。
4.3 约束表达能力
约束要写成「可执行」的规则。
常见可执行约束：
-
依赖：禁止新增依赖；必须使用项目已有库 -
版本：必须兼容某版本运行环境 -
性能：某接口在某数据量下耗时上限 -
幂等：重复请求的处理方式 -
日志：必须打哪些字段；禁止打印哪些字段 -
错误：错误码范围；异常抛出策略；重试策略 -
兼容：老接口字段不可删；新增字段默认值策略 -
安全：输入校验、权限校验、敏感信息处理
当我们把这些写清楚，模型就可以更规范的交付了。
4.4 验证习惯与测试能力
验证还是要靠工程化手段。
最低配置的验证链路：
-
静态检查：lint、类型检查、依赖扫描 -
单元测试：关键逻辑与边界条件必须有断言 -
集成测试：接口契约与关键链路 -
回归策略：哪些模块必须跑全量，哪些可抽样 -
观测：日志、指标、链路追踪的基本补齐 -
灰度与回滚：发布策略与开关方案
把这些链路搭好，AI 才能变成稳定的生产力工具。否则它更像一个加速出错的发动机。
5. 小结
程序员变成程序指导员，不是职位变了，是工作重心变了：写代码的时间变少，把问题讲清楚、把系统守住、把风险挡住的时间变多。
最近阿里出来的 P10 毕玄，在其创办的公司贝联珠贯中宣布不再按传统的专业分工，所有的人都叫 Agent 全栈工程师。
我想象中的团队也是这样，通过合并工种，减少沟通，让 AI 发挥出更大的价值。
在做这些之前，我们需要问一下自己三个问题：
-
我们的验收标准有没有变得更清晰 -
我们的测试与观测有没有跟上生成速度 -
我们有没有把隐含知识变成显性规则
答案越清楚，AI 带来的就越接近真实效率。否则只是把编码速度提上去，把返工和事故也一起提上去。
以上。