《AI Coding 工程化：从个人提效到组织升级》· AI 团队与组织 第 02 期
这个专题关注 AI 进入研发以后，团队协作与企业整体效率怎样变化。
如果用 AI 自建一个业务系统，比接入公司现有平台还省事，你会怎么选？
接现成平台，要确认接口、等对方排期，有些差异还要商量谁来改。自己做虽然要重新实现，进度却能掌握在自己手里。AI 降低了这部分实现成本，也让自建更有吸引力。
对一个团队来说，这可能是少沟通、快交付。可如果几个团队都这么选，企业就可能多出一批功能相近、数据和规则各管各的系统。单个项目即使顺利交付，几个系统需要协同处理业务时，也可能要重新对接。
我担心的是：各团队用 AI 省下了眼前的开发时间，企业以后却要为多出来的系统付出协调和整合的成本。 过去反复处理的“烟囱”问题，可能因为自建越来越省事，再次出现。
AI 让原来嫌贵的自建方案，重新有了吸引力
企业里的重复建设一直存在。有的团队赶交付，有的需求等不到公共平台支持，也有团队希望把系统掌握在自己手里。这些原因在 AI 出现之前就有。
但过去，想自己做，也得考虑人够不够、工期够不够。即使对接别人的系统麻烦，重新实现前后端、补齐测试和运行能力，也可能更贵。“公司已经有了，别再做一遍”，往往有直接的成本理由。
AI 降低了其中一部分投入。一个以前需要额外申请人手的方案，现在可能由现有成员借助 AI 就能推进。团队开始重新比较：继续等公共平台，还是自己先做出来？
自建仍然要满足生产环境的测试和运行要求，这笔账也得按相同的交付标准比较。实现投入下降，改变的是原来“人不够，做不起”的判断，让一些被放弃的方案重新进入考虑。
接入这边也可以提效。AI 能辅助理解接口、生成调用代码和执行测试。如果平台资料齐全、环境可用，复用也能变快。问题出现在另一种情况下：代码可以用 AI 写，接口该找谁、差异谁来支持、改造什么时候排，仍然要反复沟通。
当自建先被 AI 加速，接入现有能力却还在等人、等排期，团队绕开平台的理由就更充分了。
几个团队各自做快了，企业得到了什么？
拿交易系统来说，同一项交易业务可能有 App 端、PC 端、大客户版，以及渠道对接版。按正常设计，交易中台提供统一的核心流程，各端处理交互、客户需求和协议上的差异。
实际建设时，这些版本经常不在一个团队手里。各有各的需求和排期，接中台需要对接、沟通，自己实现则可以在本项目里安排。用上 AI 以后，原来让团队犹豫的开发投入又少了一些，各自做一套就更容易成为选择。
这些团队完全可能知道复用的好处。他们只是先解决了自己手里的交付问题。
于是 App、PC、大客户和渠道各有一套交易处理逻辑。对于几个版本都要执行的公共规则，企业也有了几份独立实现和不同的负责团队。
眼前省掉的跨团队沟通，可能在以后变成协调多套系统的工作。
假如企业要统一调整一条交易受理规则，就需要确认几个版本分别影响哪些业务、是否有合理例外、由谁修改、什么时候一起生效。某个版本暂时不能改，其他版本要不要等，也需要有人决定。
AI 可以帮助几个团队改代码、做验证，但这些工作建立在一致的业务决定上。给不同团队各配一个更强的 AI，并不会自动约定好谁负责公共规则、哪些差异允许保留，以及版本怎样配合发布。
如果以后还要整合，就得重新梳理已经分开的数据、规则和调用关系。开发时省下来的时间，有一部分可能又花在这里。
多端应用本身没有问题。界面、协议、客户体验当然可以不同；独立业务也可以有自己的系统。这里要关注的是：同一项公共能力是否被各团队分别定义、分别维护，以后每次调整都要重新协调。
用 AI 提效，合理架构的底线仍然要守住
使用 AI 依然要守住合理架构的底线。该统一的交易核心，不能因为再写一套变便宜了，就由各团队分别实现、各自维护。 哪些能力应该共用，哪些差异应该留在各端，要按业务关系来设计。
守住这个底线，也要让团队有办法按时交付。可以先把 AI 用在接入已有系统上，减少理解接口和编写适配代码的工作。
仍以新增一个交易渠道为例。如果企业已经有交易受理和查询能力，团队交给 Coding Agent（编程智能体）的任务，就应该从这些能力出发。比如，可以这样组织一次接入任务：
基于现有交易中台接入新渠道。已有受理、查询接口的定义和调用样例；渠道的请求字段、结果格式与回调要求见协议。
先对应哪些要求可以直接复用，哪些需要渠道适配，哪些是现有能力缺口。确认方案后生成适配代码，在测试环境验证约定的业务用例，保留调用结果和未解决的问题。
假如渠道要求批量提交，中台只有单笔受理接口，就需要先确认：每笔交易能否独立成功或失败？如果可以，渠道层就可以组织调用、汇总结果；如果要求整批同时成功或失败，就要进一步评估中台是否支持这种处理，不能直接按普通接口适配来写。
这类业务含义明确后，再让 AI 整理字段映射、生成调用代码、转换结果与回调，并运行测试。研发验收时也能看清，哪些工作复用了已有交易核心，哪些差异由渠道处理，哪些缺口还需要平台支持。
但这些资料不能每次都由接入团队到处找。平台需要把接口定义、可运行样例和测试入口维护在固定位置，让人和 AI 都能直接使用。否则，换了 AI 写代码，接入方仍然得逐个找人问清楚。
AI 能不能帮助企业减少重复建设，取决于复用这条路是否也能让它直接参与。 一份接口文档或一句提示词保证不了结果，需要用真实接入任务检验：是否调用了现有核心，差异处理是否正确，原来反复找人确认的问题减少了多少。
AI 也能让中台建设更快
如果中台确实缺能力，业务又等不起排期，只把接入做得更顺还不够。中台自身的建设速度，也应该借助 AI 提上来。
过去中台容易遇到的一种瓶颈，是几个业务团队的需求都集中到一支平台团队。补功能、做回归、维护文档和支持接入，都是同一拨人在做。需求一多，就排不过来，业务团队自然觉得自己做更快。
AI 能帮业务团队写系统，也能帮中台团队补能力、做回归、维护接入材料。过去这些环节的效率瓶颈，同样可以用 AI 来改善。 既然业务团队的开发成本需要重新估，中台的建设成本和响应速度也应该重新评估。
延续前面批量交易的假设，如果评估后确认需要补公共能力，就可以由研发确定整批成败的规则，让 AI 辅助完成实现、补充失败场景的测试，并回归 App、PC 等现有入口。通过评审和验证后，由中台统一提供，各端继续处理自己的协议差异。这样补齐一次能力，后续有同类需求的团队就可以继续复用。
公共能力也不一定全部由平台团队亲自写。条件允许时，可以由业务团队借助 AI 提交实现，平台团队负责边界确认、审查和统一发布。原来准备在渠道项目里重做交易核心的投入，就有机会用来完善大家共用的能力，也减少所有需求都等平台团队动手的情况。
平台与业务团队仍要及时决定能力归属、规则取舍和交付安排。在此基础上，用 AI 加快实现、回归与接入支持，再看公共能力补齐用了多久、新团队接入是否更快，以及已有业务有没有受到影响。
确实需要独立建设时，同样要把后续责任算进去。比较自建和复用，至少要放在相同的交付要求下看这几项：
| 要算的投入 | 需要明确的责任 |
|---|---|
| 从开发到验证、上线 | 由谁完成，依赖哪些团队，时间花在哪里 |
| 运行与后续规则变更 | 谁长期维护，公共规则改变时谁负责同步 |
| 跨系统协作与整合 | 需要谁配合，独立实现是否增加后续迁移工作 |
这些投入不一定都能立刻换算成钱，但不能因为当前需求没有排这部分工期，就当作不存在。
写在最后
各团队都在用 AI，企业仍然可能再次长出烟囱。如果自建越来越快，公共能力的建设和接入却停在原来的速度，团队绕开平台的冲动就会越来越强。
合理的架构仍然要坚持，过去中台让人等得久的问题，也有了借助 AI 改善的机会。把这部分开发、验证和接入支持做快，共享核心的架构就更有条件支撑业务交付。
企业推广 AI，除了让各团队更快交付，也要让公共能力更快建好、更容易复用。 同一项能力完善后能服务更多团队，AI 带来的提效才更有机会累积成企业整体的收益。
我会继续更新 AI Coding 和企业 Agent 的真实实践。更多系列内容，欢迎关注公众号「真老A计划」，微信搜索名称即可找到，头像和这里一样。
