# 别只盯着 AI Coding，真正的变化发生在整个研发流程 — 拆解

- 对应原文：[[别只盯着AICoding-真正的变化发生在整个研发流程]]
- 来源：微信公众号「腾讯技术工程」；作者：danteyang
- 发布：2026-10-09 17:36；获取：2026-10-10
- 文章性质：企业内部实践复盘 + 平台数据自述。核心数据（254 条需求、68% 端到端完成率、51% 两小时内完成）均来自 OK 平台运营方自述，无第三方审计，且文内前后两处口径不一致（见「证据边界」）。

## 一句话

AI 端到端交付的瓶颈不在编码速度，而在需求质量、方案质量和审查标准；当某个流程环节只是为补偿「人做不到」而存在时，正确动作是重建流程，而不是加速旧流程。

## 五个核心观点

1. **零基追问是全文的方法论内核**：对每个流程环节只问一句——它是因人的局限而存在，还是问题本身需要它？前后端分离、接口文档、需求评审会、联调阶段，作者判断四项都属于前者，因此是可被 AI 消除的摩擦，而非必须保留的工程环节。
2. **AI 擅长执行，人擅长判断；但「判断」里大部分只是信息没流通**：文章把人在研发各环节的动作列成表（需求分析、方案设计、编码、测试、部署、运维），发现人真正在做的是岔路口的决策。关键推论是：这些判断中不可替代的部分（价值取向、隐性上下文、异常识别）远小于因信息衰减而产生的部分。
3. **端到端的第一道门是需求质量，不是开发速度**：需求模糊导致返工，且"写得越快、返工越贵"。OK 平台的解法是访谈式需求评审而非清单式校验——先复述理解求确认，再顺着回答继续挖，对极模糊需求做 2~3 种解释的发散收敛，并把「必须明确」（做什么、为谁做、关键业务规则、验收标准）与「建议明确」分开。
4. **第二道门是方案质量，好方案是施工图而非提纲**：技术方案 AI 的硬纪律包括按依赖图自底向上排序、垂直切片优先、单步不超过 5 个文件或 2 个子系统、每 2~3 步插入验证检查点，并对关键决策做一次"假设作者过度自信"的找茬自审。方案阶段改方向成本最低。
5. **编码与审查的关键是"收窄"而非"变强"**：手术刀式编码三条纪律（简单优先、范围纪律、关键路径先写测试）；代码审查改用"改善即批准"——只有会导致 bug / 崩溃 / 安全 / 数据损坏 / 功能缺失 / 越权的关键问题才阻塞，纯风格建议不得阻塞合并。这套标准的目的不是降质量，而是消除风格差异带来的无谓返工。

## 七个分析角度与开头钩子

### 1. 零基思维：流程存在的理由是什么
- 你有没有问过，需求评审会到底是因为"问题需要它"，还是因为"人做不到才需要它"？
- 把每个环节问一句"去掉它会怎样"，会砍掉多少看起来天经地义的流程？
- 当 AI 能同时持有前后端上下文，"对协议"这件事还有存在必要吗？

### 2. 信息衰减：为什么最终上线的东西不是用户想要的
- 用户说"太麻烦"，上线变成"减少点击步骤"——中间丢失的到底是什么？
- 如果每一次角色交接都衰减一次信息，那开会的本质是不是在给衰减打补丁？
- 用一份结构化 Spec 替代口头传递链，信息为什么就不再被"翻译"？

### 3. 需求质量门：为什么瓶颈反而在需求侧
- AI 写代码越快，为什么需求模糊的代价反而越高？
- 访谈式追问和清单式校验，差的是流程还是理解深度？
- 需求提出者不必变成技术专家——那到底该谁把细节补齐？

### 4. 方案即施工图：为什么方案阶段最省钱
- 为什么"按重要性排序"的方案，会让开发 AI 频繁撞上尚未创建的前置依赖？
- 单步触碰 5 个文件就该拆，这个数字背后是哪种失败模式？
- 在方向还便宜修正的时候找茬，和上线后回滚，成本差几倍？

### 5. 范围纪律：AI 的"顺手"为什么是风险
- AI 顺手清理相邻代码，为什么每个"顺手"都是潜在的 bug 引入点？
- "发现但不碰"这个机制，保留了什么、又避免了什么？
- 简单优先原则让过度复杂类问题减半——是模型变聪明了，还是约束变清楚了？

### 6. 改善即批准：审查标准该怎么改
- 追求 90 分今天上线，和追求 95 分明天上线，哪个对业务更值？
- 把问题严格分成"关键"和"改进"两档，为什么能消灭无谓返工？
- 安全六项为什么不能进"建议"档，只能进"必须修复"档？

### 7. 知识飞轮与角色升级：人的位置在哪
- 人的角色没有消失——但为什么会从"执行者"变成"知识供给者"？
- 过期的知识为什么比没有知识更危险？
- AI 不知道自己不知道什么，所以"前置强注入"胜过"被动召回"？

## 最小实践（对 Seetong 的可迁移动作）

1. **挑一个跨端重复排查点，先试零基追问**：不急着上工具，先把 iOS / Android / SDK 三端一次典型需求的全流程写成环节清单，逐项问"这个环节是因为人的局限，还是问题本身需要"。产物是一份"可消除摩擦清单"，而不是新平台。
2. **把需求四要素变成硬门禁**：在 TAPD 需求模板里固定"做什么 / 为谁做 / 关键业务规则 / 验收标准"四项为必填，其余（优先级、异常场景）为建议。先拦"注定会在开发阶段卡住"的需求，不做评分游戏。
3. **给方案文档加依赖序与检查点**：要求技术方案按"存储 → 协议 → 业务逻辑 → 调用方"排序，每 2~3 步写一个可执行的验证锚点（能编译、能跑通基本 CRUD），并把不确定点统一收进"待确认问题"。
4. **先在小团队试"改善即批准"**：明确只有会导致 bug / 崩溃 / 安全 / 数据损坏 / 功能缺失 / 越权的问题才阻塞合并，风格类建议不阻塞。用"返工轮次"而不是"代码完美度"衡量效果。
5. **给知识库加退场机制**：如果要沉淀项目知识，先设计 TTL、失效反馈通道和随主干 commit 刷新的机制，否则知识库会从资产变成污染源。

## 关联

- [[02-ai-coding/面向Skills编程-淘宝企业购端到端研发提效实践]]：同为"企业内端到端研发提效"的大厂实践，那篇以 Skills 为组织单位，本文以九阶段流水线 + 质量门为组织单位。
- [[02-ai-coding/AICoding之后-如何让Agent进入企业研发全链路-得物推荐的Harness实践]]：都主张"用结构化产物替代口头传递"，本文补上需求评审与方案自审这两道前置门。
- [[02-ai-coding/Anthropic发布AI-Native软件开发流程-时代变了-该换套模式了]]：同一主线的另一种表达——从"人机分工"转向"流程重建"。
- [[01-ai-agents/阿里妹-端到端业务需求专家Agent-4层架构8步流程]]：那篇给出需求侧 Agent 的架构与流程，本文给出需求质量门的判定标准（四要素 + 七维评分）。
- [[01-ai-agents/腾讯程序员-Agent的上限可能不在模型而在团队知识]]：本文"知识飞轮"与那篇"团队知识供给"是同一命题的不同侧面。
- [[06-ai-tech/Harness不是目的，知识才是护城河：一个 AI 工程交付团队的知识沉淀实践]]：那篇讲知识如何成为护城河，本文讲知识如何老化退场。

## 证据边界

- **文内数据前后矛盾**：第二章给出 2026 年 4~6 月"提交 254 条、AI 端到端完成 172 条（68%）"，知识资产"合计 547 条"；结语又给出"运营至今 170 条需求端到端自动交付、66% 实现率、491 条知识资产"。后一组数字低于前一组，与"这些数字还在涨"的表述冲突。两组口径也无法确认是否同源。
- **分母口径不清**："68% 端到端完成率"的分母是提交需求数，而第九章"安全中心当前约 30% 的需求可通过 OK 平台开发实现"是另一口径。两个数字不可互为验证或互相引用。
- **跨来源数据为二手**：TAB 实验平台"研发周期从 5 天缩短到 2 天（↓60%）、额外发现 30% 遗漏影响点"注明来自 TAB 团队对外分享材料；"角色间等待占交付周期 40~60%"仅说明"根据我们对多个团队的调研反馈"，未给样本量与调研方法。
- **司内调研无方法学**："约 85% 的团队仍停留在个人编码加速"及"中层 60~72% 周期压缩、需求理解效率提升约 80%"均未给分母、样本范围与统计口径。
- **九阶段未被完整列出**：正文称"整个流程九个阶段"，但阶段明细在抓取到的正文中缺失（原文疑似以图片或表格呈现）。因此本页不列举九阶段清单，避免补造。
- **立场**：文章由 OK 平台建设方撰写，平台能力与收益属自述；"改善即批准""简单优先使问题减半（49 条需求、约 17%）"等均为平台内部观察，非对照实验结论。

标签： #主题/AI-Coding #主题/AI-Agent #主题/研发效能 #主题/知识管理 #场景/公众号长文