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

原文链接：https://mp.weixin.qq.com/s/s_AmjWIB57b7fQY_3VNkoQ
来源：微信公众号「腾讯技术工程」；作者 danteyang；发布 2026-10-09 17:36
获取：2026-10-10；经 Playwright 抓取正文，正文 SHA-256 见归档文件
对应摘要：拆解摘要 · 原文归档

核心结论（一句话）

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

分类提炼

场景：企业内 AI 研发流程重建（OK 平台，腾讯安全中心场景）；类型为平台运营方自述的实践复盘，非对照实验。
定位：02-ai-coding。本文以软件研发交付全链路为对象，给出需求评审、方案设计、编码、审查、知识沉淀五个环节的具体工程纪律，属于 AI Coding 的流程与质量门设计，不是通用 Agent 架构综述，也不是宏观行业分析。
与现有条目的关系：本文在”端到端研发提效”主线上补的是质量门的判定标准（需求四要素、七维可行性评分、审查两档分类），而现有条目多给架构、工具或组织视角。

知识节点

零基思维：对每个流程环节只问一句——它是因人的局限而存在，还是问题本身需要它。作者据此判断前后端分离、接口文档、需求评审会、联调阶段四项都是前者，因而可被 AI 消除，而非只被加速。
信息衰减：需求从用户到上线每经一次角色交接就衰减一次，评审会与联调期的本质是给衰减打补丁。用同一份结构化规格贯穿全链路，是让衰减消失而非被压缩。
结构化Spec：需求评审 AI 产出的精炼需求描述（功能点 + 业务规则 + 验收标准）不是给人看的摘要，而是后续所有 AI 共用的精确输入，替代口头传递链。
需求质量门：端到端的第一道门。核心判断是”写得越快、返工越贵”，因此把质量门前置到需求侧。做法是访谈式追问（先复述确认，再顺着回答挖，对极模糊需求做 2~3 种解释发散收敛），并把”做什么 / 为谁做 / 关键业务规则 / 验收标准”列为必须明确项。
可行性评分：七维打分（需求清晰度 20%、仓库匹配度 20%、改动范围 15%、技术复杂度 15%、外部依赖 10%、风险等级 10%、交付形态 10%），总分 ≥60 才进入开发流水线。定位是保护机制，不是通关游戏。
垂直切片：技术方案按一条完整功能路径切分（建表 + 接口 + 最小可用逻辑 = 一个可验证切片），每个切片完成后系统保持可编译可验证；配合依赖图自底向上排序、单步不超过 5 文件或 2 子系统、每 2~3 步一个检查点。
范围纪律：开发 AI 必须且只能改动方案列出的文件；运行中发现的范围外改进点记录到”发现但不碰”清单，而不是顺手修改。相邻代码的每一次”顺手”都是潜在 bug 引入点与审查噪声。
改善即批准：代码审查标准——只要变更确实改善了整体代码健康度就应通过。只有会导致 bug、崩溃、安全漏洞、数据损坏、功能缺失、越权的问题才是关键问题并阻塞合并；命名、注释、风格等改进建议一律不阻塞。安全六项（登录态取 UID、鉴权中间件、SQL 参数化、敏感信息不硬编码、边界校验、资源归属校验）例外，命中即关键问题。
知识飞轮：每次交付都把可跨需求复用的结论沉淀为技术方案模板、经验复盘、踩坑记录、PRD 模板；配合前置强注入（平台按需求类型/仓库/关键词打包最相关知识塞进入参，注入率从”AI 自主决定”提升到 90% 以上）与老化退场机制（TTL 到期复核、knowledge_feedback 反馈降置信度、随主干 commit 增量刷新架构文档）。
能力四象限：①AI 100% 端到端（Bug 修复、前端增改、标准 CRUD、简单业务迭代）；②人机协同·风险侧（AI 做 60~80%，人推审批，如简单 DDL）；③人机协同·复杂度侧（AI 做 50~70%，人做架构决策与模块拆分）；④暂不支持（资金流、核心安全链路、跨仓库复杂联动、数据迁移与灰度发布）。

关联图谱

上游（基于 / 来自）

[[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落地-我们做对了什么]]：本文”关键路径先写测试再实现”“编译通过但单测失败”与那篇的稳定断言、测试资产沉淀互相印证。
[[02-ai-coding/得物技术-Delivery-Harness-可控AI交付]]：本文的范围纪律、检查点与审查两档标准，可视为其证据门禁在单需求粒度上的实现细则。

同级（横向 / 并列）

[[01-ai-agents/腾讯程序员-Agent的上限可能不在模型而在团队知识]]：本文”知识飞轮”与那篇”团队知识供给”是同一命题的两个侧面——一个讲如何让知识循环，一个讲知识为何决定上限。
[[01-ai-agents/端到端10倍提效-英伟达研发团队如何用Agent重塑工作流]]：同为厂商侧端到端提效叙事，可对比其指标口径与证据强度。
[[06-ai-tech/Harness不是目的，知识才是护城河：一个 AI 工程交付团队的知识沉淀实践]]：那篇论证知识是护城河，本文补上反面——若老化退场没做好，飞轮会变成垃圾循环。
[[01-ai-agents/Loop-Engineering-验证才是瓶颈]]：本文的检查点、前置质量门与那篇”验证才是瓶颈”指向同一个结论：产出速度不是约束，验证能力才是。

方法与证据

主链路：需求提交 → 访谈式需求评审（必须明确四项 / 建议明确若干）→ 七维可行性评分（≥60 通过）→ 仓库匹配 → 技术方案（依赖序 + 垂直切片 + 检查点 + 找茬自审 + 待确认问题）→ 手术刀式编码（简单优先 / 范围纪律 / 关键路径先测试）→ Code Review（改善即批准 + 安全六项硬核对）→ 部署 → 知识蒸馏回写。

原文自述的运营数据（4~6 月窗口）：共提交 254 条需求、AI 端到端完成 172 条（68%）；51% 的需求在 2 小时内完成；对照基线为传统模式简单需求从提出到合并的中位耗时 3~5 个工作日。知识资产合计 547 条（技术方案模板 223、经验复盘 111、踩坑记录 112、PRD 模板 101），近 7 天新增 200+ 条。约 49 条需求（约 17%）在自动开发阶段经历了超过 1 轮审查 + 修复。

人的四个不可替代节点：决策与方案选型、补充隐性上下文、异常识别与干预、最终价值判断。作者给出一个具象反例：舆情管理端标签拆分需求，AI 完成了前端显示与后端接口存储，但遗漏了需同步修改的关联巡检 Skill，否则会产生入库 Bug——这类遗漏源于缺乏全局视角，需人在 Review 时补充。审查颗粒度因此从行级升到意图级。

对 Seetong 的可借鉴动作

需求模板加四要素硬门禁：TAPD 需求固定”做什么 / 为谁做 / 关键业务规则 / 验收标准”必填，其余为建议补充。先拦注定卡壳的需求，不做评分游戏。
方案文档加依赖序与检查点：三端 + 2 SDK 的技术方案按”存储 → 协议 → 业务逻辑 → 调用方”排序，每 2~3 步写可执行验证锚点，不确定点统一进”待确认问题”。
跨端改动先划范围，再执行：把方案列出的文件清单作为硬边界，发现的范围外问题写进”发现但不碰”，避免 AI 顺手重构相邻代码。
小范围试”改善即批准”：明确只有 bug / 崩溃 / 安全 / 数据损坏 / 功能缺失 / 越权才阻塞合并，用返工轮次而非完美度衡量收益。
知识沉淀先设计退场：若要建项目知识库，TTL、失效反馈通道、随主干 commit 刷新三者要一起设计，否则会从资产变成上下文污染源。

证据边界与限制

文内数据前后矛盾：第二章为”提交 254 条 / 完成 172 条 / 68% / 知识资产 547 条”，结语为”运营至今 170 条 / 66% / 491 条”。后一组低于前一组，与”这些数字还在涨”冲突；两组口径是否同源无法确认。
分母口径不可互换：”68% 端到端完成率”的分母是提交需求数；第九章”安全中心约 30% 的需求可通过 OK 平台开发实现”为另一口径，两个数字不能互为验证。
跨来源为二手数据：TAB 实验平台”5 天 → 2 天（↓60%）、额外发现 30% 遗漏影响点”注明来自对方对外分享；”角色间等待占交付周期 40~60%”仅称”根据我们对多个团队的调研反馈”，无样本量与方法。
司内调研无方法学：”约 85% 团队停留在个人编码加速”、中层”周期压缩 60~72%、需求理解效率提升约 80%”均未给分母、样本与统计口径。
九阶段清单缺失：正文称流程共九个阶段，但抓取到的正文中没有阶段明细（疑为图片或表格），本页不列举，避免补造。
来源立场：文章由平台建设方撰写，能力与收益为自述；”简单优先使过度复杂类问题减半”“49 条需求需多轮返修”等均为平台内部观察，非对照实验。
可迁移边界：本文结论建立在”单仓库、低复杂度、低风险”需求上（约 30% 需求范围）。跨仓库联动、资金流、核心安全链路等场景作者自认不适用，向 Seetong 三端 + 2 SDK 迁移时需先按能力四象限重新划界。