两个月AI写码，员工存个草稿再打开还没跑通

英国一家小型慈善机构的运营负责人Pete，带着两个内部项目来求技术评估。项目用AI编码代理做了大约两个月，代码、测试、项目文档都攒了不少，但最基础的一条端到端结果至今没演示出来：一名普通员工保存自己的信息，关掉应用再打开，另一名员工看不到它。

他把自己定位成业务负责人，不是动手写代码的开发者，并且明确表示愿意被告诉"我们选错了"或者"我们把事情搞复杂了"。两个项目的源码和评审材料放在同一个公开仓库里，他只要求先看其中一部分，不指望有人把全部内容审完再开口。

两个项目，两套保存设计

第一个是KPI与员工工作计划。员工选核心KPI、自建影响力KPI、选发展行为、设季度目标，需要能保存一份未完成的私人草稿，回头再改。更大的流程还包括提交给经理、请求修改、批准并锁定版本、季度进度更新、证据和汇总报表。

技术栈是SharePoint Framework、React和TypeScript。草稿保存的设想是：通过员工本人登录的连接，更新一条私有的SharePoint记录；另一条受保护的记录存放归属人、年份、状态和指向可编辑草稿的链接；经理审批是独立流程。Pete的问题是，这种拆分和它的权限控制是否与需求相称，以及现有代码到"可靠安装的应用"之间还缺什么。

第二个是报销与里程。员工在一个月度报销单下录入多条费用行，选科目代码，附上收据或说明为何没有收据，并记录里程；经理逐行批准或质询；财务审核后导出数据供工资流程使用。

同样是SharePoint Framework、React和TypeScript，但保存设计不同：浏览器提交一个私有请求，由一条受信任的Power Automate工作流负责确认员工身份、校验报销单，并写入费用及相关记录。设计里包含重复请求处理、版本检查、收据、报销总额、处理结果、审计记录，以及写入中断后的恢复。Pete特别希望有人质疑：这些处理和校验的量，对他们的实际需求是否合理。

AI交付的组织方式

这套做法涉及项目负责人兼顾问、交付PM、构建代理，以及独立的技术、安全和QA评审角色。Pete本人提供业务需求、做决策、负责用户验收。

流程上用了需求与冲刺计划、隔离的代码分支与工作树、GitHub、自动化测试、评审证据，以及代理会话之间的交接。开发在Windows机器和GitHub托管的检查上跑，另有一个独立的Microsoft 365测试环境。

本意是让归属清晰、检查独立。实际反复出现的情况是：单项检查或评审做完了，下一个交付步骤却没启动；交接、审批问题、后续功能开发反复发生，而第一个能用的保存功能始终没完成。他想知道，是不是协调和管理做得太多了，更简单有效的AI辅助交付模式该长什么样。代理是用来帮着造软件的，不是放进成品应用里替员工做审批决定。

卡在哪

代码是有用的，历史上也出现过自动化测试通过。KPI项目还推进了私有测试记录搭建、普通用户读取和进一步的源码接线。

但这些都还不能证明：当前安装的版本能通过完整的保存、重新打开和双用户隐私检查。报销项目同样只有处理代码，没有演示过、也没有被接受的已安装保存流程。

剩下的问题包括：首条记录创建、接通预定的服务、对齐数据结构与权限、选对源码版本、执行相关测试，以及安装同一个经过检查的版本。此外还有浏览器报错、本地脚本错误和工具拒绝执行，这些需要与真正的应用缺陷、交付管理问题区分开，而不是统统归成一个"进度慢"的解释。

他想被评审的五个方向

• 架构与平台选型：SPFx、SharePoint加Power Automate是否合理？哪些该留、哪些能简化？现成模板、Power Apps或其他方案是否真能减少剩余工作量？原则上想用上已有的Microsoft 365投入，但接受有理由的替代方案。
• 代码与应用设计：有没有多余的层、重复的做法、缺失的连接？归属、权限、审批规则和数据关系是否放在了对的位置？怎样让应用更好维护？
• 保存、安全与恢复：让员工保存并重新打开自己信息的最小安全路径是什么？首次创建、编辑冲突、重复点击、网络响应不确定，以及报销项目里的收据和写入半途中断，分别该怎么处理？
• 测试与发布：哪些测试先跑？怎么证明一个通过的模拟测试与真实Microsoft 365行为之间的差别？用什么证据把源码版本、测试、安装包和用户验收串起来？
• AI交付结构：到底几个代理角色有用？任务、项目指令、上下文交接、评审和人工决策该怎么组织？有经验的人类开发者该在哪儿接手？怎么避免协调代理花的力气比交付软件还多？

他还想要一份可执行的恢复计划：每个项目按顺序给出接下来三到五个动作，第一个小冲刺交付什么、怎么证明它完成了。任何估算最好把编码、配置、测试和外部等待分开列。

仓库里有什么，缺什么

评审包里包含实际实现源码与测试、工作流生成器、图表、数据结构信息、报销项目的需求和交付计划、未解决问题、验收场景和发布评审记录。最好的起点是一份代码阅读指南，它标出了相关入口，省得评审者翻遍整个仓库。

限制是刻意设置的：这是一份独立的评审副本，不是可直接部署的检出；私有记录、凭据、真实租户配置和原始开发历史都不在里面；缺失的测试夹具和资源有文档说明；源码快照对应的是不同开发阶段，指南里有解释。

Pete说，有用的回复可以短到一句话："这个连接缺了""这个权限设计比必要的复杂""这三个测试能确定到底什么在真正工作"。回复可以留在帖子里，也可以在GitHub开issue，最好指明项目、文件或函数、问题所在，以及最小的修改或测试建议。他也不要求任何人接触生产环境或真实的员工、财务记录。