已有业务如何走向 AI-Native 研发：从协作规范到 PEC
在上一次 AI-Native 研发的尝试里，我把从想法到产品的协作过程整理成了 build-product-zero-to-one。它帮助我和 AI 一起明确业务问题、产品范围和设计，再把这些判断传递到实现中，让每次开发的质量更稳定。
那篇文章最后，我留下了一个困惑：一个人可以更高效地完成产品，但当业务已经运行了很久，又有多个人共同维护时，AI-Native 研发应该怎样发生？
最近经过对大厂的AI-Native研发重构研究以及自己的实践探索之后，我发现完整解法其中的一块拼图会是 Product Engineering Context（PEC），一个面向人和 Agent 的上下文管理系统：把业务规则、产品行为、代码和数据库设计，以及它们之间的关联，有组织地记录下来，并随着业务变化持续维护。这会是已有业务迈向 AI-Native 研发的一项关键基建。
这篇文章想把这个判断再往下推一推，也说说我准备从哪里开始做。
一个人跑通之后，团队为什么还离不开“找对人”
从 0 到 1 做产品时，很多上下文天然集中在我这里。我知道某个需求为什么出现，为什么放弃另一种方案，也知道一处改动可能影响哪里。Agent 缺少信息时，我可以随时补充。
我的 zero-to-one skill 已经在保存 BRD、PRD、领域模型和架构等产品上下文。但如果面临一个团队的已有业务，知识来源会复杂得多：不同时间的需求文档、不同人的设计决定、已经发生变化的实现，还有从未被完整记录的约定。每个人熟悉的部分也不一样。
这时，一个业务需求进来，产品或运营通常要先找到对应负责人。需求涉及几个模块，就要继续找到另外几个人。这里面有职责分工，也有很现实的知识依赖：得找到知道这段业务如何实现、为什么这样实现的人。
假设一个购物网站，每买一单送 10 积分，退款时把这 10 积分扣回。现在运营想把每单赠送的积分改成 20，于是找负责下单功能的研发修改。但退款功能由另一个人维护，新来的运营并不知道退款时还有一处扣积分的逻辑。
如果只改了下单功能，就可能出现买一单送 20 积分，退款却只扣回 10 积分的情况。研发即使按规范完成了修改和测试，也可能因为不知道这条关联，漏掉退款那一边。
规范可以要求开发者检查影响范围，但具体有哪些关联，仍然需要可查、可验证的上下文。
当这些理解主要由个人掌握时，换人的学习成本就一直存在。即使每位研发都配上 Agent，提需者仍要找人，负责人仍要解释历史，跨模块的联系仍要靠有人记得。编码更快以后，这部分等待和反复确认也不会消失。
PEC：让业务理解成为人和 Agent 都能使用的组织资产
我设想的 PEC，会把业务规则、产品行为、代码和数据关联起来，让人从业务问题出发，就能自动找到相关上下文。比如把“退款要扣回赠送的积分”关联到下单和退款的实现，调整赠送积分时，就能提醒两边一起检查。
这份知识可以由产品、运营、研发和 Agent 共同使用。原本需要找负责人反复解释的业务，现在有了可查询、可复用的记录。换一个人或 Agent 接手，也能沿着这些关联理解问题，减少重新摸索的成本。我认为，这正是 PEC 值得作为团队基建来建设的原因。
从已有业务出发，把上下文接入、组织并用起来
我目前把这件事分成三层来看：
- 数据的打通和收集。把分散的业务文档、产品资料、代码和数据库定义接入进来，为理解已有业务提供材料。
- PEC 的建设。借鉴 Palantir 的 Ontology（本体论）思路，围绕业务对象及其关系组织这些材料，再把业务与产品的含义关联到代码和数据。
- PEC 的消费。通过搜索等方式，让人和 Agent 从业务问题出发，找到相关上下文，用于需求讨论和研发。
这三层是我目前对这个系统的初步划分，具体怎样建设，还需要继续探索。
不同业务需要不同的 PEC，这也是我想探索的机会
最近我看到 FDE（Forward Deployed Engineer）开始多了起来，也就是深入客户业务与技术环境、参与方案落地的工程师。在 Anthropic 与 Accenture 的合作公告里，也能看到这类工程师参与企业 AI 落地的安排。我认为，前面这三层中有一些工作可以标准化，PEC 会是值得探索的一个方向。
但在我的实践里，不同行业的公司，对 PEC 的构建会有思路上的差异。怎样理解业务、怎样组织业务与工程之间的关系，会影响 PEC 的建设方式。这也意味着，除了通用能力，还有围绕不同行业构建 PEC 的机会。
我已经做了一个很初步的 make-pec，尝试从已有应用出发，把产品与业务知识关联到代码和数据库。这个版本还有很多地方需要调优，我会沿着这个方向继续探索。