AI R&D Management 研发管理AI Coding |
💡核心观点 AI 研发管理不是少管理，而是少仪式，多前置约束。仪式减少是收益，约束前置是方法。 |
很多团队上 AI Coding 之后，会遇到一个挺别扭的现象：
工具明明变强了，流程却没有变轻。
PR 开始堵，审批跟着变多。管理者担心风险，就更频繁地开会、填表、同步状态。
最后结果是，AI 确实把代码写快了，但团队没有真的快起来。
新增产能，又被旧流程吃回去了。
说明范围：这篇讲的 AI Coding，指的是 Copilot、Cursor、Claude Code 这类嵌入开发流程的代码生成工具。聚焦在这些工具进来之后，研发团队的流程和管理该怎么适配。
01. AI 上线后，流程为什么反而变重
过去很多研发流程，是围绕"写代码很贵"长出来的。
排期会用来分配稀缺工程师，设计文档用来减少返工，代码 review 用来守住质量，状态表用来同步进度。
这些流程不一定错。它们适合低吞吐时代。
但 AI Coding 进来以后，吞吐变了。以前一个需求要写两天，现在半天就能出一个版本。以前一个方案要讨论很久，现在可以很快试出几个方向。
如果旧流程不变，团队就会变成：
PR 等人看，需求等人确认，状态等人同步，风险等人开会判断。
这时候，管理者很容易再加一层控制。但这不是解决新瓶颈，而是在旧流程上继续加流程。
Anthropic 工程团队在分享 Claude Code 内部实践时提到过一个关键观察：组织中的流程很少自己消亡。一个会议被创建之后，即使它的原始目的已经消失，也几乎不会被主动取消。团队更常见的应对方式不是清理旧流程，而是在旧流程之上叠加新流程。 |
AI 带来新产能，旧流程不会自动退出。没人清理，它们就会继续消耗团队注意力。
02. 该减少的不是管理，是低价值仪式
减少仪式，不是不要流程。真正要减少的，是那些不再服务决策、不再提升质量、只是在维持组织安全感的动作。
比如没有新信息的状态会。大家轮流讲进度，听起来透明，但真正的问题没有被解决。
再比如手工维护的状态表。每个人把 Jira、飞书、Git、PR 里的信息重新搬一遍，只是为了让另一个人看得更舒服。
还有一种更常见：为了留痕而留痕的文档。写完没人读，读了也不更新，最后和真实代码越来越远。
这些东西过去还能补信息差。但在 AI 高吞吐环境里，它们会变成摩擦。
代码生成变快后，最贵的不是"谁把代码敲出来"，而是几个更靠前的判断：
1.这件事该不该做 2.验收标准是什么 3.边界条件有没有写清楚 4.出了问题谁能解释 |
如果这些问题还靠会议和口头提醒来补，团队一定会越来越累。
AI 时代的管理，不是把人叫到一起确认一遍。而是让系统在错误发生前挡住它。
03. 约束前置：从"事后补"到"事前挡"
约束不能少。而且要更早。
约束前置，不是多写几页文档，也不是搞一套重流程。它的意思是：把关键规则放到 AI 能读、系统能校验、团队能复用的位置。
这里说的"前置"，不是多一个环节，而是换一个位置。原来靠会后补充的东西，放到任务开始前。原来靠老员工提醒的东西，放到 checklist、spec、模板或 repo 里。原来靠上线前紧张检查的东西，放到 CI、测试和权限规则里。
至少四类约束要提前：
1. 需求验收标准 不要等 AI 写完之后，才发现"我以为你知道这个边界条件"。AI 不知道。它只知道你给了什么上下文。完成标准、覆盖场景、不能破的边界、不能退的指标，都应该在开发前讲清楚。 |
2. 业务规则和边界条件 很多团队真正依赖的不是文档，而是老员工脑子里的经验。老员工知道哪个按钮不能删、哪个接口不能改、哪个客户有特殊逻辑。但 AI 读不到这些默契。如果规则只存在于人的脑子里，高吞吐只会把隐性规则撞得更快。 |
3. 测试、CI 和发布门禁 这不是让流程更重，而是让低级问题不要反复回到人面前。能自动检查的，就不要靠会议检查。能在 CI 里挡住的，就不要靠上线前拍脑袋。 |
4. 安全、权限和合规边界 权限、支付、数据、用户隐私这些路径，不能靠"模型应该会懂"。边界必须提前写进规则里。 |
CASE一个真实场景
有一个做 SaaS 的中小团队，6 个工程师，上了 Cursor 之后产出翻倍。但问题也跟着来：一周内连续出了两次线上事故，都是 AI 改动触碰了老业务逻辑——一个是删了一个看似无用的兼容字段，导致旧客户数据异常；另一个是修改了支付回调的超时参数，触发了风控。 这两条规则以前全靠那个干了三年的后端老员工口头提醒。 后来他们做了一件事：花两天时间，把这类"绝对不能碰"的规则整理成一份BOUNDARIES.md，放在 repo 根目录。文件很短，只有 40 多条，格式是"路径 + 规则 + 原因"。然后在 AI 生成代码前，把这份文件作为上下文喂给模型；同时在 CI 里加了一条检查：如果 PR 改动涉及这些路径，自动触发相关 owner 的 review。 两周后效果很明显：同类事故归零，老员工的 review 负担反而减轻了，每周的同步会也从 3 次减到了 1 次。 |
这就是约束前置的核心逻辑——规则写清楚了，会议才有资格减少。
这种做法和软件工程中"Spec-driven development"（规格驱动开发）的思路一致：先定义清楚系统该做什么、不该做什么，再开始实现。区别在于，过去 spec 是写给人看的文档，现在它还要成为 AI 执行前的约束——成为计划、任务和自动检查条件的一部分。
文档不是消失了。文档要从旁路说明书，变成工作流的一部分。
04. 原则统一，实践下放
一讲约束前置，很多团队会走向另一个极端：要求所有小组用同一套模板，所有需求都走同一套审批，连不同类型的 PR 也套同一张检查表。
这也不对。约束前置，不等于集中管控。
更合理的方式是：原则统一，实践下放。
该统一的是底线：
• 安全敏感代码必须有明确 owner • 核心业务规则必须有测试 • 需求进入开发前必须有验收标准 • AI 生成的关键改动不能越过人类责任边界 |
但具体怎么做，可以交给小组适配。有的团队可以先从 checklist 开始，有的团队更适合把常见规则放进 repo。也可能当前最该补的是 CI，或者先改 bug triage 和排期节奏。
中小团队尤其不要一上来就搭巨大平台。
先从最容易出事故、最容易反复沟通、最容易靠老员工口头补洞的地方开始。把它变成一条明确规则，再放到 AI 执行前。这就够了。
ACTION从今天开始
如果团队上了 AI 之后，会议更多、表格更多、审批更多，那不一定是管理升级。很可能只是旧流程在消耗新产能。
先找一个最消耗沟通的环节。把其中一条隐性规则写清楚，放到 AI 执行之前。
然后观察：那个环节的会议和返工，是不是开始减少了？
如果是，你就找到了起点。下一步是把这个方法推广到更多环节，把更多"口头约定"变成"系统可读的规则"。
这不是一次性的组织变革。这是 AI 时代研发管理的持续练习——每减少一个仪式背后，都对应着一条被前置的约束。 |
粤ICP备14082021号
免费POC，
零成本试错
