这两天我一直在做一个实验：能不能把软件研发流程，从需求提出、澄清、写 PRD、排期、技术方案、开发、测试、验收，尽可能放进一条自动化链路里。
做着做着，反而更加确定一件事：今天大家都在讲 AI Coding，但编码只是研发流程里的一段。真正消耗组织时间的，往往不是“代码怎么写”，而是需求怎么对齐、上下文怎么传递、谁来判断边界、谁来追踪卡点、谁来把结果同步回项目现场。
业务方以为自己讲清楚了。产品经理以为自己听懂了。技术团队到了实现层，又发现有权限、状态、异常、旧系统和边界条件没有说透。于是同一个需求会在聊天、会议、文档、任务平台和代码库之间来回搬运，最后每个人都很忙，但流程没有真正跑起来。
企业 AI 下一步真正要解决的，不是让 AI 更会写代码，而是让 AI 能进入流程，接走一段可控工作。
一、AI Coding 的热闹，遮住了研发流程里更大的时间黑洞
如果只提升编码效率，研发流程不会自动变短，只会把更大的瓶颈暴露得更早。
AI 写代码确实越来越强。GitHub 早期关于 Copilot 的实验显示，在清晰任务里，开发者完成同类编程任务的速度可以明显提升。OpenAI 在 2026 年发布 Codex 相关能力时，也把软件开发从“单次补全”推进到更长周期的任务执行。
但真实研发不是只把代码写出来。一个需求从被提出到上线，中间有大量非编码动作：确认目标用户、判断业务价值、补齐边界、查历史决策、看旧代码、排期、拆任务、设计验收、处理延期、通知相关方、回看状态。编码提速以后，这些动作不会消失，反而会变成新的主战场。
所以我不认同一种说法：AI 时代不需要 PRD，也不需要需求对焦了。恰好相反，AI 让需求对焦变得更重要。过去你没说清楚，人会在沟通里慢慢补。现在你没说清楚，AI 会更快地替你猜，然后更快地把错误做出来。
研发流程的核心变化，不是“人不写代码了”。而是每个环节都要被改造成 AI 能看懂、能执行、人能验收的结构。
二、数字人不是聊天入口，而是所有人进入流程的前台
真正有价值的数字人，不是长得像人，而是站在真实协作关系里替人看见、澄清和推进。
我设想的人机协同空间，第一层不是传统页面，也不是一个孤立工作台。第一层应该是交互层。业务方可以像平时一样在协同软件里发消息、提需求、追问进度。区别在于，接住这条消息的，可能不是某个一直在线的人，而是绑定了身份、上下文和规则的数字人。
这个数字人不是客服机器人。它背后有完整的工作记忆：历史需求、项目计划、会议结论、产品策略、代码资料、权限边界、团队协作方式。业务方说“我想加一个功能”，它不能只回答“好的，我记录一下”。它要先追问目标、场景、范围、验收方式，再回到代码库和历史需求里看：这个功能以前是不是讨论过，限制在哪里，做完会影响哪些模块。
它澄清完以后，自动生成需求，推送到远程需求平台。每天固定时间，它扫描已经落盘、延期和卡住的需求，给负责人发提醒。如果负责人觉得某个需求还不够清楚，可以在需求评论区 @ 需求评审数字人，让它继续扒上下文、提出问题，再把需要澄清的内容发回业务方。
这时数字人不再是“多一个入口”。它变成了流程前台：所有人的入口从这里进来，流程的第一轮澄清也从这里开始。
三、人机协同空间的底座，是流程驱动的协作场
平台真正要承载的不是 AI 聊天，而是流程从触发到闭环的一次运行。
我更愿意把第二层叫协作空间，或者流程驱动的协同底座。一个项目，本质上就是某条流程跑起来以后形成的实例。一个研发需求，就是从需求流程里长出来的一次运行。一个合同评审、采购申请、客户交付、营销活动，也都是流程实例。
如果没有这个底座，数字人和 Agent 会散在各处。一个在群里回答，一个在网页里生成文档，一个在本地代码工具里写代码，一个在任务平台里改状态。看起来每个点都很智能，但组织仍然靠人肉搬运上下文。
协同空间要做的，是把这些动作放到同一个流程语境里：谁发起了什么事件，当前处在哪个节点，需要哪种上下文，应该由人处理还是 Agent 处理，结果回到哪里，状态如何同步，下一步谁接手。
这就是“流程驱动”的含义。不是先问“哪个 AI 最强”，而是先问：这件事在流程里的位置是什么？它读什么信息，做什么动作，输出什么结果，风险由谁兜底？
四、平台层要管四件事：流程、引擎、上下文和项目
没有平台层，AI 只能做零散动作；有了平台层，AI 才能进入组织协作。
第一件事是流程编排。平台要定义节点、分支条件、人机混合步骤和标准模板。比如需求提出后，是先自动澄清，还是先进入产品评审？什么情况下需要技术预审？什么情况下可以直接进入排期？这些不是 AI 自由发挥的问题，而是流程规则问题。
第二件事是引擎编排。流程告诉你“这件事应该怎么协同”，引擎告诉你“每一步谁在什么时候接手”。这里的“谁”可以是人，也可以是 Agent。一个需求到了技术澄清节点，可能先由代码理解 Agent 扫描相关模块，再由产品负责人确认影响范围，最后由开发者接任务。
第三件事是上下文管理。每一步都要拿到该拿的信息，但不能拿多。需求 Agent 需要历史需求、业务目标和产品资料；代码 Agent 需要仓库结构、相关文件和技术约束；评审 Agent 需要验收标准、风险边界和延期记录。上下文不是资料堆得越多越好，而是按流程节点精准注入。
第四件事是任务和项目承接。很多自动化失败，不是前面没有生成内容，而是后面没有落到项目管理里。平台要管理任务生命周期、项目实例、进度追踪、卡点识别和结果回写。否则 AI 做完一段活，组织不知道它做了什么，流程也不知道下一步该谁接。
五、运行时必须中立：不要把流程绑死在某一种 AI 能力上
企业真正要长期经营的，是流程资产和运行协议，不是某一个 Agent 框架。
第三层是运行时层。这里可以是云端智能体，可以是本地代码工具，可以是企业自研执行器，也可以是某个专门做文档、数据、测试或浏览器自动化的 Agent。重要的不是它叫什么，而是它能不能通过统一协议接收任务、拿到上下文、返回状态、交付结果。
这也是我为什么强调运行时中立。企业一旦把流程绑死在某个 AI 工具上，短期很爽，长期会很难受。工具会变，模型会变，安全要求会变，供应商策略也会变。真正稳定的，应该是流程、数据、权限、日志、评测和交付标准。
平台层像一个调度台。它不需要自己拥有所有 AI 能力，但它必须知道：这个任务适合哪个运行时，应该注入哪些上下文，允许调用哪些工具，最长执行多久，失败如何回传，产物怎么归档，状态怎样同步。
这样一来，企业就不会被某一种 AI 能力绑架。今天让本地代码 Agent 处理技术方案，明天让云端运行时处理资料整理，后天让专门的测试 Agent 做回归验证，平台都能用同一种流程语言把它们接起来。
六、一条需求从聊天到落盘，应该怎样自动跑起来
全自动化不是把人拿掉，而是让每个节点都知道自己该自动到哪里、停在哪里。
拿研发需求举例。业务方先在协同工具里提一个想法：希望某个项目看板增加延期预警。身份级数字人先接住消息，不急着建需求，而是追问三个问题：谁需要看预警，预警依据是什么，提醒之后要触发什么动作。
业务方补充以后，数字人去看历史需求、会议结论和产品现状。如果发现过去做过类似讨论，它会把差异列出来。如果发现代码里已经有部分能力，它会标出可能复用的模块。如果边界仍然不清，它继续追问，而不是把不清楚的问题甩给开发。
澄清到一定程度后，平台生成需求卡，带上目标、范围、验收标准、关联上下文和风险提示。需求进入评审节点。负责人可以直接在评论区让评审数字人再检查一次：是否缺少异常状态，是否影响权限，是否需要技术预研。
当需求被指派给开发者，平台监听到状态变化，自动把需求摘要、上下文链接、关键风险和预计交付物通知开发者所在协作群。开发者接到的不是一句“你看下这个需求”，而是一段已经被结构化、可追踪、可验收的工作。
这才是 AI 进入研发流程的样子。不是替产品经理偷懒，也不是替开发者接锅，而是把过去散落在脑子、群聊、文档和代码里的信息，组织成一条可以连续推进的链路。
七、为什么一定是流程驱动，而不是 AI 驱动
AI 可以执行、整理、建议和推进，但流程必须负责定义秩序。
很多人听到多 Agent，就会本能地想让 AI 自己规划全流程。这个方向有想象力，但在企业现场很危险。因为真实流程不是只有“下一步做什么”，还包含权限、责任、合规、优先级、组织关系、客户承诺、预算约束和异常处理。
AI 很适合接走可定义、可观察、可回滚、可评测的一段活。比如整理需求、补齐字段、初步检查材料、生成风险清单、扫描代码影响面、催办逾期任务、汇总项目状态。这些节点可以自动化，也应该自动化。
但流程的骨架不能交给 AI 即兴发挥。哪些节点必须人工确认，哪些动作只能建议不能执行，哪些权限只能读不能写，哪些情况要暂停，哪些结果要进入审计，都必须由流程和治理规则提前定义。
这也是 NIST AI 风险管理框架、OWASP Agentic Applications 安全框架反复提醒的方向：当 AI 系统具备规划、行动和跨系统执行能力时，企业不能只看输出聪不聪明，还要看治理、度量、回放、责任和风险控制。
八、企业真正要建设的，是人和 Agent 的共同工作秩序
人机协同空间的终点，不是 AI 替代人，而是人从重复推进者迁移到规则设计者、判断者和兜底者。
在这个空间里，人不是被挤出去。相反，人要更清楚地定义自己的价值。业务负责人负责定义真实目标和优先级，产品负责人负责把模糊意图转成可执行范围，技术负责人负责判断实现边界和系统风险，流程负责人负责设计节点、权限、日志和验收方式。
Agent 也不是孤立工具。它是空间成员。它有自己的角色、任务、权限、上下文和交付物。它可以被调度，可以被评审，可以被替换，也可以被暂停。它做得好不好，不只看回答像不像人，而看它有没有让流程更短、返工更少、状态更清楚、风险更可控。
这对业务项目、IT 项目和大型跨部门流程都有价值。你管理一个产品需求，可以这么做。你管理一个咨询交付，也可以这么做。你串一个采购、合同、付款、交付的端到端流程，同样可以这么做。关键不是“有没有 AI”，而是有没有一套能让人和 AI 在同一个流程骨架里协同的空间。
企业 AI 最怕两种极端。一种是把 AI 当成万能大脑，什么都让它自己判断，最后不可控。另一种是把 AI 永远关在聊天框里，只做问答和润色，最后没有组织复利。更稳的路，是让流程负责秩序，让平台负责沉淀，让运行时负责执行，让人负责判断和升级。
九、最后：流程变成空间，AI 才开始进入组织
下一代企业协同，不是人开会、AI旁听、平台记账，而是人和 Agent 都在同一个流程空间里工作。
过去的项目管理平台，主要记录任务和状态。过去的流程平台，主要定义规则和审批。过去的 AI 工具，主要回答问题和生成内容。人机协同空间要把这三件事重新接起来：让协同入口能感知需求，让流程平台能组织任务，让运行时能执行一段工作，让结果和状态回到同一个空间。
这件事最适合从小流程开始，不要一上来追全公司全自动。先挑一条高频、重复、结果可验收、风险可控的流程，比如需求澄清、审批材料预审、项目周报、合同初审、客户资料更新。先把触发源、输入材料、角色权限、人工确认点、异常暂停和回写状态写清楚，再让数字人和 Agent 进去跑。
跑起来以后，组织会看到一个很关键的变化：流程不再只是文档，也不只是审批线。流程变成了一个空间。人在里面定义目标和边界，Agent 在里面接走任务，平台在里面沉淀上下文，运行时在里面提供执行能力。每一次运行结束，结果、状态、经验和失败原因又回到空间里，成为下一次协同的上下文。
这才是我理解的 AI 流程管理。不是让 AI 替你把所有事情自动做完，而是把组织里那些反复发生、反复沟通、反复返工的工作，改造成可触发、可分派、可执行、可回看、可迭代的协同结构。
企业真正要抓住的，不是“我有没有用了某个最强 AI”。
而是：我的流程里，有没有一个人和 AI 都能共同工作的空间。
十、参考依据
1. GitHub：《Research: quantifying GitHub Copilot’s impact on developer productivity and happiness》，用于验证 AI Coding 在清晰编程任务上的效率提升。 查看来源
2. Google Cloud / DORA：《2024 Accelerate State of DevOps Report》，用于参考 AI、组织系统和软件交付表现之间的关系。 查看来源
3. OpenAI：《Introducing Codex》，用于参考软件开发 Agent 从对话走向长周期任务执行的变化。 查看来源
4. NIST：AI Risk Management Framework，用于参考 AI 风险治理、度量和管理框架。 查看来源
5. OWASP：Top 10 for Agentic Applications 2026，用于参考具备规划和行动能力的 Agent 系统风险边界。 查看来源