我之前说过，现阶段通用大模型基本能力包括通识、推理、成本、效率，都没什么问题了，那么他一定会演进为某“通用垂直领域的偏科模型”，而事实上也确实如此：
现阶段基座模型有很大的精力都是围绕 Coding 展开的
关于为什么选 AI Coding，或者产研这个领域，之前我们也有过探讨，无非是 Coding 首先最好做，其次他既是通用能力，又具备收集垂直领域知识的能力，什么意思呢？
意思是，GitHub 提供了海量优质数据，搞 Coding 这批人对于程序员的 KnowHow 又尤其熟悉
最后就是一旦这个工作台做好后，各行各业只要用它去实现业务，基模就有可能完成优质垂直领域数据收集
整个一套是阳谋，说实话挺聪明的，所以最近一年 AI Coding 演进的速度很快，而从去年下半年开始就已经有很多优秀实践案例了，比如：
《AI Coding 实战：10年祖传系统，54万行代码，2周重构结束》
这里可以下个结论就是：AI Coding 对于每个个人的效率提升的有效且夸张的！
但现在有个实际且尴尬的情况是：个人提效 不等于 整体提效，现阶段团队层面的提升，相较于个人就很不明显了。
所以技术负责人的课题就出来了：团队要怎么和 AI 合作，这个问题比 Coding 工具选型更重要：
过去，研发侧最大的两个卡点依次是需求产出与开发/测试，举个例子：
一个中型需求，写代码可能要两周，再加上前后沟通、测试、验收，整体交付周期经常被拉到一个月。大型需求就更不用说了，往往严重滞后于业务迭代节奏。
但使用 AI Coding 工具的话，情况发生了巨大的变化：以前两周才能写完的代码，现在可能两三天就能完成。
于是前面所述的新问题也就出现了：
代码变快了，但交付并没有等比例变快
因为 AI Coding 把编码这个环节提速之后，研发链路里的瓶颈开始转移，原来的另一个卡点就变得尤其显眼了：需求产出不行、需求歧义太多。也就是说：
AI Coding 解决了代码生产效率，但它不会解决产研协作效率
为了解决业务与产品的沟通问题、产品与研发的沟通问题、研发随便与谁的沟通问题，我们做了很多努力，最终在基于 SDD 的项目协作落地探索（用到了 Spec-Kit 这类工具）中获得了不错的成绩，其中最大的感受是：
AI 真正进入研发流程后，各种规范、Skills 就很重要了
举个例子，就在昨天，就有个粉丝问出了毕竟接近问题本质的问题：
我疑惑的是，作为一个个人，应该怎么去做更合适；
背景：
我是前端出身，进入一家做agent 的公司，做全干；
但是公司是任务制，也就是按照整个任务都是你做，可能设计前后 agent, 当然我是前端，所以分配到的任务可能更偏重前端的；因此也有 java 的同学，他们会做更偏重后端的任务；
但是在我做需求的时候，简单的写个 java 接口， ai 完全没问题
但是涉及到多个表的创建关联，有的时候 ai 写出来的能跑，但是可能不符合规范；
卡点：
java 同学说我现在设计到核心代码，需要补充架构能力，cr 的时候不能只告诉他，是与神对话写出来的代码；
疑惑：基于此，我感觉我要补充后端的架构能力； 然后，又看到叶总说的，后面我们代码都是 ai 写，就应该让 ai 去学，而不是自己去学；
如果你深入去理解他的问题，从个人角度的逻辑是：
第一、AI Coding 人与 AI 的工作边界是什么，或者说我们是否需要具备对 AI 输出内容的判断能力，或者就直接信任 AI？
比如就按粉丝所述的：与神对话写出来的代码？
第二可能要考虑得更长远的，站在团队层面，AI 怎么做整体赋能…
其实把这些问题再次打开，梳理成大家更容易理解的问题的话，我觉得可以是：
一、AI 到底应该根据什么来实现？
这个问题就很复杂，如果只是根据产品的一段口头描述（包括群聊会议纪要什么的）去写代码，那问题就很明显：没有标准的输入，就不要期待稳定的输出。
毕竟，AI 这东西，你要他快很容易、你要他完整也很容易，但你要他正确却很难…
真实业务系统中，需求不是孤立存在的，它会牵涉旧功能、各种莫名其妙异常边界，只要在 AI Coding 这里稍有实践，大家会发现：有没有稳定的上下文让 AI 消费这件事挺重要的。
二、很多重复的流程究竟该怎么处理？
无论用 AI 做什么，比如我经常让 AI 帮我取标题，那么都一定会有一套流程（现在叫 Skills 也许大家更能理解）；
这东西到了 Coding 这里，就更为明显了，因为代码这东西的规范就很多，这时候很多重复的问题就出来了，比如每次都要告诉 AI：
你先看需求
再拆任务
......
再自查一遍
就我们之前的实践：一个动作只要出现第二次就可以考虑沉淀下来，如果出现三次直接无脑 Skills 化就好了。
所以，今天的话题也就出来了：
我们讨论团队级 AI 提效，其实是需要改造整体流程的，这里需要一整套的流程、机制需要去构建，不仅是技术问题
这个就是各个技术负责人必须面对的底层问题：当代码生产速度被 AI 拉起来后，到底应该如何重构研发协作机制去整体提效？
标准定义、分层逻辑
其实所有的事情都有方法论，大家不能胡乱抓瞎，既然再聊 AI 团队提效，那就一定绕不开一个话题：好坏的标准是什么？
也就是作为一个技术负责人，要先做一个判断：你们团队现在到底处在哪个 AI 研发阶段。
而这个问题的上一层是：AI Coding 团队协作（意思是只关注研发链条，不去扩展公司链条），到底有几个层次，这个分层得出来！
一：纯人工阶段
古法编程是最传统的研发模式，我是觉得他们是值得佩服的，但这批人可能会有点固执：
去年下半年的时候，我给某产业团队做咨询一个问题造成了我与对方负责人互相鄙视的结果：我鄙视甲方技术负责人从来不写提示词，甲方鄙视我不写代码。
但因为他是甲方，最终是我被鄙视了…
而古法编程大家很熟悉，就是靠人就好，这里问题明显：效率和质量高度依赖个体经验：
-
一个经验丰富的产品经理，可以把需求写得很清楚； -
一个架构师，可以少踩很多坑； -
一个好测试，可以覆盖更多边；
但一旦团队规模变大、项目变多，效率就要出问题，这里常见的现象就是：到一定规模，项目加人效率可能更低。
原来我是认为 AI Coding 也不能解决这些问题，但真实情况是这个人越强，AI 对他的加持就越强，所以大家懂的…
二、人机协同
这是多数团队现在“应该”进入的阶段，我之前其实想写实际处于的阶段，但真的大家出去看一圈中小型公司，真的不是那么回事…
而现阶段的 AI 自媒体多少是有些浮夸的，所以闹得最凶的是AI 又替代了谁、又优化了多少多少…
这给我们实际去企业做咨询时候就带来了不小的困难，因为老板的心被吹花了，而我们做的东西又比较务实，比如定义清楚人和 AI 的职责。
一般来说结论是：AI 负责执行，人负责判断和审核。这句话很简单，但任务是需要具体拆开的，比如：
人机协同这件事是比较容易的，因为只涉及个人，然后还非常容易拿到成绩。
三、自动化交付
再往后，才是很多人想象中的多 Agent 协同。
从需求分析、方案设计、代码生成，到测试执行、上线发布，很多环节都可以由 AI 自动推进…
只不过，要达成这一切有一个管理前提：研发流程要具备很高的标准化，也就是我们常说的标准作业。
这个标准作业系统，是管理机制设计、执行的结果，他是 AI 从局部工具变成流程执行者的关键参数。
但做过管理咨询的同学会更清楚：多数公司仅仅是口头在乎管理而已，他们是不会去做机制建设的，所以多数团队根本没有那个架构设计能力与管理意识能够做好标准作业系统。
从 古法编程 到 人机协同
一个普通研发团队，如何从古法编程走到人机协同？这里有个参考步骤：
-
流程标准化 -
需求结构化 -
知识库建设 -
Skills 沉淀
一、流程标准化
如果一个需求进来以后，团队自己都不知道下一步该怎么走，那 AI 也不会知道，比如：出了事故谁处理…
什么都靠人临时协调，那一定不标准，而想要标准也不难，就是把一个需求从提出到上线拆成固定阶段，比如：
这个东西其实跟 AI 无关，有没有 AI 都应该做，而且也不难，无非两个点：
-
有哪些阶段，顺序是什么？ -
每个阶段，输入是什么、输出是什么、谁来评价（审核）？
说白了就是梳理 SOP，能让 AI 参与的，尽量让 AI 参与即可。
只不过大家在做这部分工作时候要注意：不要偷懒也不要想当然，因为：AI 不会补位。AI 要么有上下文，要么没有上下文；要么有规则，要么没有规则
如果你想糊弄 AI，那么他一定会糊弄你
二、需求结构化
就我之前的工作经历来说：技术最大的敌人是产品，产品最大的敌人是业务（商务或销售），因为上游喜欢偷懒，给的东西很烂，上下游之间的交付物不清晰，就容易扯皮，扯皮就是内耗。
AI 的出现会让之前隐藏的问题就会变得尤其显眼：毕竟需求不清楚，代码越快、返工越多…
最后，关于标准物的交付如何评价，这东西在之前会很主观，现阶段这种主观的评价会尽量丢给 AI，下面是一个对比图：
三、知识库建设
根据上面的工作：流程标准化 + 需求结构化后，AI 团队协作的基本环境才准备好，但这还没完，还有一个更麻烦的问题：AI 如何去理解你的业务和系统呢？
很多团队用 AI Coding 时都会遇到一个现象，东西做出来看着像模像样，然后各种问题就爆发了：权限问题、异常处理问题……
具体建设不同团队经验会不一样，但有三件事应该是类似的：内容结构化、版本管理、持续更新维护。
四、Skills 沉淀
所谓 Skills，就是把这些重复动作封装成可复用能力，比如：需求澄清、PRD 生成…
至于 Skills 怎么写，我们之前的文章做了大量介绍，这里就不做展开了，确实感兴趣小伙伴可以看这里：
当流程、需求、知识库和 Skills 逐渐建立后，就可以开始尝试做全链路 AI 化：
全链路 AI 化
全链路 AI 化其实就是先分环节、然后每个环节也就三件事：有固定 skill、有结构化输出、有人兜底
PS：如果你做过数字化转型，就一定看得出来，这依旧是组织变革的一部分。。。
这里为了更好的说明，我们做个研发链路的例子：
业务提出需求
碎片化的东西没办法形成 PRD，所以在需求提出时候需要：统一模板，把原始需求整理成标准化需求初稿，比如需求背景、目标用户等信息写清楚。
现在我们在做需求时，会让 AI 先出 Demo，再围绕 Demo 做讨论，效率会高很多。
产品梳理需求
产品阶段是要想清楚问题，AI 的价值就又来了：识别需求中的模糊表达、生成待澄清问题…
人要主要是做判断、做更新。很多流程都可以被做掉，包括：需求对齐、UI 设计…
篇幅有限，我这里就不继续了，有兴趣可以看我 AI 原生团队的文章：
结构化输出
全链路 AI 化有一个很重要的要求：每个环节的输出，都应该尽量结构化。也就是：上游产出必须成为下游输入
比如 PRD 输出给开发时：
这样的结构，下游 AI 很容易消费。
前面的知识差不多了，最后我们再说说 SDD 的价值：
SDD 的价值
到这里，再回头看 SDD，大家会更容易理解它的价值：让需求、计划、任务、实现、测试、验收这些产物被串起来。
Spec-Kit 是我们使用的方案，但他只是其中一种轻量实现，他有很多优点：
/specify：先把需求和约束讲清楚
/plan：再把技术方案拆明白
/tasks：然后拆成可执行任务
/implement：最后让 AI 按规范实现
只不过如果放到全链路研发里看，只有这几步还不够。
因为真实团队不是从 /specify 开始的，前面还有业务输入、需求澄清、原型对齐；
/implement 也不是结束，后面还有测试、验收、上线、复盘…
所以更完整的链路应该是：
这里最后强调下核心思想：让规范成为研发主线，让 AI 在规范约束下执行，让验证和反馈把规范持续校正。SDD 真正要形成闭环，必须有这条链路：
规范 → 实现 → 验证 → 修复 → 回写，这也是 Spec 和普通文档最大的区别。
只不过 SDD（Spec）价值虽大，但他要做好是很难的，Spec 如果要变成工程资产，就必须参与实现、参与验证、参与修正，并且持续更新。
一般团队很难玩好，原因我们之前就说了，这是管理问题，背后是管理成本。
AI 不背锅
我们之前咨询的一个团队，西湖村了一个非常搞笑的 Case：
大家都觉得 AI 做了，于是没人负责
也就是出了问题，都在给 AI 甩锅，只可惜 AI 不怕锅，但他接不了锅：
所以每个环节都要明确责任人：这里的责任的重点是保证 AI 产出有人审核、有人背锅。
但这种东西不能落在口头上，喊口号一定会出事，所以还是得上机制、上奖惩，这样整个系统才会真正跑起来。
具体来说，三个方面要注意下：
第一，过程留痕。输入、输出、审核意见、修改记录都要保存。
第二，标准明确。要有质量标准，比如需求完整性标准、代码审查标准、上线检查标准等。
第三，问题可追踪。上线后如果出现问题，要能追溯追踪哪里有问题。
总而言之就一句话：
出了问题以后，团队能更快知道问题从哪里来，下一次如何避免。
结语
篇幅差不多了，我们开始收尾，今天不说废话，总结几个建议给大家：
一、找最痛的点
很多团队受老板蛊惑（强迫），一上来就想做全链路 AI 化，但这很容易失败。
因为流程改造牵涉的人太多，铺得太大，阻力一定很高，技术老大往往没有能力去推动；
因为据我所知，老板在关键时候一定会隐身，做得好是他的功劳，做不好就是你的锅…
所以更现实的方式是先找最痛的点，比如如果团队最大问题是需求模糊，那就先做需求结构化和需求澄清。
先把一个点做透，让团队看到效果，再逐步扩展到全链路，这样会好很多，至于老板的期待这个事情，那还是需要你自己去向上管理的…
标准要先行
个人 AI 提效是工具熟悉度的问题、团队 AI 提效是管理机制的问题。
如果想做 AI 自动化，就一定要做标准化，建议团队先把几个关键模板定下，包括需求文档、验收标准……
然后，做模板这里也是一样，先有再优，别想一口气吃个胖子…
Skills 化
Skills 的本质是 SOP/Workflow，现阶段网上有很多现成 Skills。
但实际使用下来：效果不是太好，所以这些东西可以参考，想长久稳定还得自己下功夫。
就我们之前的经验：好的东西是不会给你的…
定义人的工作
虽然现在老板们很喜欢讨论 AI 会替代多少人，但从真实研发实践来看，未来很长时间内，更现实的状态都是人机协同。两者之间的工作要各有侧重：
-
AI 适合做大量重复、结构化的执行工作。 -
人适合做判断和兜底。
所以技术负责人要重新定义人的工作重心，比如：开发少写样板代码，多做架构判断。
最后回归之前我们 AI 原生团队的探索：
最好收个尾：今天介绍的是产研团队的小闭环，希望今天的文章对大家有用吧…