史伟莎技术服务平台
iOS 工程治理与 AI 协作研发

接手复杂工程，探索可控的 AI 协作研发

项目开始于 2026 年 7 月。我接手时，已有 AI 生成的界面与业务代码，但需求资料不完整，Demo、Mock 和正式接口之间缺少清楚的对应关系，部分页面集中承担了大量职责。继续开发之前，需要先判断哪些行为可信、哪些实现应该保留，以及每次修改应该止于哪里。

我在推进 iOS 核心业务的同时，逐步承担需求澄清、任务拆分、方案判断、代码审查和验收工作，并尝试通过子代理、代码索引、项目知识库和定时续办，扩大有限时间与额度下能够完成的工作范围。

这段经历最大的收获，是认识到当前 AI 研发仍需要持续的人为判断。从目标到可交付结果，中间仍有试错、纠偏、验证和总结；新模型、新工具也需要结合实际问题验证，再决定怎样使用。

项目周期： 2026.07-2026.10，指项目时间范围。
我的职责： iOS 业务开发、工程治理、AI 任务组织与质量把控。
业务范围： 登录、签到、工单详情、SOP 执行和签离等核心流程。
技术环境： Swift、SwiftUI、UIKit、Combine、Moya、MVVM。

1. 先弄清楚，开发应该以什么为依据

平台面向消杀技术人员，通过标准作业流程规范上门服务。接手时的困难除了代码复杂，还包括业务依据不清楚：页面上的限制是否经过确认，Mock 是否代表真实数据，Demo 的变化是否应该同步到正式工程，都需要重新判断。

最初尝试从 Demo 提取产品与 UI 基准，但随后发现 Demo 随着业务变动，本身也存在错误，不能整体作为权威答案。工作因此转向核对正式工程、接口资料与已确认行为，并通过人工校准形成可使用的依据。

这个过程让我认识到，生成一份看起来完整的需求文档并不够，必须说明内容来自哪里、哪些已经确认、哪些仍然未知。

这一分工经历了演进。到 2026 年 10 月 20 日，知识库已收录的业务正文被确认为当前业务基准，Demo 降为参考，并同步更新项目标准与资料入口。业务基准确认、TestFlight 提交与功能验收分别记录；已收录范围以外的内容、待确认事项和实际运行状态，仍需各自的依据。

2. 把反复沟通的问题，转为可以执行的约束

AI 能快速生成实现，但如果目标、权限和工程边界不清楚，也会快速扩大修改范围。我逐步将协作要求分层维护，减少不同资料之间的冲突。

个人协作要求：判断依据、授权、表达和交付要求
项目工程标准：平台、架构、依赖、UI、接口与数据边界
专项技能：复杂分析方法和具体工具操作流程
待确认事项：当前缺少依据、尚不能决定的内容

重点约束包括：调查和讨论不自动扩大为实施；重构保持已确认的业务和界面；改变接口、数据语义或依赖前明确范围；交付时分别说明实际修改、验证结果与未验证范围。

规则本身也需要维护。遇到重复问题时，我会检查要求是否冲突、是否难以执行，以及 AI 是否真正遵守。例如，实施与构建授权曾存在表述冲突，后续统一为实施包含相称的本地构建和测试，运行 App、真实网络和外部影响则分别确认。

完成的治理计划也不应永久堆积。后续结合源码核查及已确认的分批回归，将长期模型规则并入项目标准，再清理旧计划、过时分析和失效引用，让日常入口保留当前有效内容。

3. 审核 AI 的结论，追查触发条件与业务影响

AI 给出看似合理的判断后，我重点核对三个问题：什么操作会触发，现有代码或接口是否允许，以及会产生什么实际影响。

案例一：把假设风险与当前缺陷分开

2026 年 10 月 15 日的一次审查中，AI 使用人为构造的异常数据证明某些处理存在风险，随后将其列入必须修复的清单。我继续追问正常操作能否产生这些输入，以及是否存在真实业务资料受影响的证据。

重新核查后，问题被分为三类：

该会话随后记录了对编译、绘图点位对应关系和节点分类等明确问题的处理，以及当时的构建与专项检查结果。这些历史记录只说明当时的验证范围，不能替代当前版本或整条业务流程的验收。

这次纠偏形成了后续审查习惯：测试可以证明某个输入下的处理结果，认定业务缺陷还需要核对支持范围和预期行为。

案例二：检查相关改动是否真的必要

2026 年 10 月 17 日的一次字段适配中，我发现 AI 将首次绑定笼统称为“补绑”，要求继续核对是否做了额外操作。重新追查调用链后，确认部分新增状态同步可以由既有列表刷新和详情请求取得，同时识别出未充分说明的绑定入口变化。

这轮审查明确了哪些逻辑应保留、哪些扩展可以收敛。它不能被描述为已经阻止了线上事故，但能说明我会追查改动必要性和行为范围，而不是只凭解释完整或构建通过就接受全部实现。

案例三：细微改动，也会改变业务结果

AI 生成和修改代码的速度很快，业务规则有时会在几行看似普通的调整中发生变化。一个典型的数值处理例子是：

两种实现都能编译、运行，差别在于业务要求。原规则要求直接截断时，改为 3.5 就改变了结果。这个例子说明，审核不能停留在语法、命名和代码结构，还要检查计算、精度、条件与成功判定等细节是否保持原来的含义。

因此，我把“代码对不对”拆成两个问题：实现能否正常执行，以及执行结果是否符合已确认的业务规则。对这类容易被常规写法替换的细节，先明确输入和预期结果，再围绕改动检查代表性输入与边界值。

这个数值例子用于说明业务规则变化，不计作本项目中已定位到具体文件的缺陷。

4. 组织多个 AI 执行，保留人工决策和阶段验收

2026 年 9 月起，我多次明确采用子代理分步实现、主会话负责管理与审核、本人真机确认后再继续的方式，并根据任务指定模型和推理强度。

明确目标和边界
    → 拆分步骤
    → 子代理实现
    → 主会话或其他子代理复核
    → 本人检查差异及实际表现
    → 推进下一阶段

任务交接说明已有结论、允许修改的文件、禁止扩大范围的事项和完成标准。审查时结合当前工作树、调用链、接口约定及构建结果，检查实现是否完整、是否引入额外行为。

我也会检查工具使用方式是否方便审阅。例如，曾明确要求在当前工作区执行，让修改可以在 SourceTree 中看到，避免意外创建独立工作区后难以确认差异。

分工增加了可同时处理的工作范围，也带来上下文传递、等待和重复审查的成本。因此，代理数量和审查轮数都需要服从实际任务，交叉核查也不能替代业务验收。

5. 尝试新技术，让工具服务于实际问题

我持续关注模型与开发工具的变化，围绕代码定位、资料理解、审查和资源管理尝试新方法。

曾观察到代码索引工具把不相关文件列为依赖，因此没有将工具给出的文件数量或风险等级直接作为结论。新工具先通过局部样例验证，再决定是否扩大使用。

这些实践改善了我的工作可控性。对于 Token 减少和错误减少，目前有使用反馈与具体纠偏案例，尚无统一前后对照数据，因此不写节省比例或错误率。

6. 业务变动下，连夜剥离尚不成熟的离线功能

2026 年 10 月，业务调整要求优先推进在线版本，尚不成熟的离线功能需要快速剥离。此时离线分支中已经混入发票、SOP 配置、签名、拍照定位等在线业务更新，直接回退旧分支会丢掉这些成果。

我将目标明确为：以 my_flow 的在线行为为基准，在当前分支移除离线能力，同时保留已经确认的在线更新。拆分范围覆盖本地读取、持久草稿、提交队列、自动补传，以及这些能力对页面状态和提交结果的影响。

先区分保留与删除，再逐条恢复在线链路

我要求 AI 对比两个分支，按业务操作列出执行链，明确保留项及其来源。SOP、物料、简报和签名恢复直接请求与真实上传，以服务端回执确认成功；离线入口、草稿恢复和自动同步按调用关系逐项移除。

剥离中也出现了错误。AI 曾将离线开发新增的集中提交校验当作普通校验保留，扩大了在线版本原有的限制；后续交叉核查还发现客户签名在线摘要需要恢复、物料保存条件需要纠正、离线投影字段仍有残留。我继续追查代码来源和消费者，安排子代理从不同角度检查，逐项修正。

这次经历让我把删除审查的重点放在行为上：保留哪些在线能力、哪些调用必须恢复、哪些状态只能由服务端结果更新。只按目录或文件名称删除，容易把同一批开发中的在线更新一起带走。

将夜间执行与复核组织成连续步骤

10 月 17 日凌晨，我要求按步骤交给指定模型的子代理执行，主会话负责衔接和审查。随后通过定时续办继续收尾，并安排不同子代理复核保留项、残留引用和构建结果，同时设置五小时额度预留线。

凌晨 5:46 的交付记录显示，已完成 35 个源码文件的实际删除，修正物料、签名及模型残留问题，正式 Workspace 的 Debug、Release 编译和链接通过。业务界面和真实接口由后续实际验收确认。

围绕此次方案调查、离线剥离、反复核查及同会话后续在线链路调整，主会话与 14 个直属子代理累计记录约 8725 万 Token。这些消耗揭示了复杂改动的真实成本：执行之外，还包括理解混合变更、发现剥离错误和重新验证。

这次任务把业务判断、AI 执行、独立复核和额度管理放在同一条推进流程中。夜间持续执行扩展了可利用时间，人工明确保留范围和纠正偏差，使工作始终围绕在线版本的交付目标推进。

7. 让项目知识可以查询，也可以继续维护

截至 2026 年 10 月 21 日，已组织整理 23 份功能文档及对应变更历史，内容包括功能入口、主要流程、条件分支、相关接口、源码位置、数据影响、历史变化及核查范围。

正文使用 Markdown 维护，经统一模板生成本地阅读页。源码片段、相关文件指纹和 Git 基线帮助发现资料需要重新核查的情况；相关文件变化后，先分析行为差异，再更新说明和指纹，不能只刷新数值使检查通过。

维护入口也逐步统一：从正文元数据和生成清单恢复基线，结合 Git 差异和调用链判断受影响功能，再更新正文、最近更新摘要及阅读页。共享文件改变不自动代表所有关联功能都发生业务变化。

到 2026 年 10 月 20 日，已收录业务正文被确认为当前业务基准，Demo 仅作参考。旧治理计划结合源码核查和已确认回归结果完成清理，长期规则回到项目标准，过期资料在检查独有信息和引用后删除。

这项工作的产物除了文档数量，还包括资料职责、查询入口与更新路径。知识库没有覆盖的内容、待确认内容和运行状态仍然需要各自的依据，不能由文档检查通过代替业务验收。

8. Token 与成本：为后续性价比比较建立基线

记录 Token，是为了观察资源花在哪里，并在以后比较模型、工具和协作方式的投入产出。当前面板仅代表本次提供的 Codex 统计范围，其他 AI 工具的使用尚未计入；面板记录也没有逐项归属到本项目，不能当作项目 AI 总投入。

8.1 本期统计快照

B 表示十亿，M 表示百万，显示值经过取整。截图中的应用列为 Codex，供应商列为“会话日志”；它反映面板对会话日志的统计，不证明来自官方账单。

8.2 Token 主要投入在哪里

上下文复用占输入的大部分。 按面板显示值计算，37.3 亿 ÷（37.3 亿缓存命中＋1.71 亿新增输入）≈ 95.6%。这些输入承载历史对话、代码和工具结果，为多轮分析、实现和复核提供持续背景。

工作投入覆盖开发、纠错与工程建设。 本期任务包括业务实现、离线功能剥离、接口核查、代码审查，以及协作规则和知识库建设。离线案例表明，复杂任务需要为范围核对、错误修正和独立验证安排资源；规范和知识库则将其中的有效结论保留下来，供后续任务复用。

后续优化聚焦重复调查和返工。 将已确认的业务、代码关系和变更历史保留下来，让新任务复用已有结论；交接时明确范围与完成标准，减少代理重复阅读和无关扩展。比较时同时观察成本、人工时间和验收结果，判断哪些投入值得保留。

与其他开发者比较，进一步看清审查消耗。 我也与其他开发者交流过 Token 用量，整体规模大体接近，其中一段时间我的用量更高。除了业务实现，多轮代码审核也是额外消耗的来源：每轮审查都可能重新带入相同的代码、历史讨论和工具结果，缓存命中的上下文也会继续计入累计 Token。

为说明比较方法，以“某阶段多出 2 亿 Token”作差额示意，分别查看实现、审查、返工和代理协调的投入。审查消耗要结合发现的问题和避免的重复修改来评价；需要减少的是没有新证据、没有新增检查目标的反复读取。这里的 2 亿用于示意分析方法，不并入本期实测统计。

8.3 这一阶段形成的工作能力

这一阶段，我建立了从任务拆分、AI 执行、交叉审查到人工验收的推进方式，并把反复出现的问题转为项目约束和知识资料。

• 业务变动时控制范围： 快速确定保留项与删除项，围绕在线交付目标组织离线剥离。
• 复杂改动中发现偏差： 通过分支差异、调用关系和独立复核，纠正遗漏、错误保留和在线能力丢失。
• 资源受限时持续推进： 结合模型分工、额度预留与定时续办，将适合的任务延伸到夜间执行。
• 把试错转为后续可复用的资料： 维护工程约束、23 份功能正文与变更历史，形成查询和更新入口。

Token 快照为这些实践留下了投入记录，后续通过同类任务对比，继续改进成本、返工量与完成效率。

8.4 后续怎样比较性价比

比较围绕同类任务展开：在相近的输入、范围和验收标准下，分别记录资源消耗、人工参与和交付结果。

优先比较两项结果：完成一项已验收任务的 AI 成本，以及完成同项任务所需的人工时间和返工量。 一次性建设与日常业务分别记录，模型和计价变化同时注明，便于解释成本变化的原因。

每个周期保留固定截止快照，后续新增记录与本期并列比较。这样可以逐步回答：换用模型是否减少总成本，增加审查是否减少返工，知识复用是否降低了再次调查的投入，以及夜间执行增加了多少有效推进时间。

统计口径： 本期采用 Codex 面板会话日志，区间为 2026-08-10 00:00 至 2026-10-21 00:00；金额采用面板汇总值，后续费用比较补齐未定价请求，并单列其他 AI 平台与实际支付费用。39.2 亿包含缓存复用，95.6% 是输入缓存命中率。

8.5 生成速度变快后，怎样判断工时

AI 快速给出代码后，交付仍要经过业务核对、差异审查、纠偏和验收。3.49 被从截断改为四舍五入这样的变化，改动很小，但发现它需要理解原规则、定位修改并验证结果。

因此，我按交付步骤估计工作量：

人工工时：业务澄清＋实现组织＋审查纠偏＋验收回归
交付周期：结合上述步骤的先后关系、并行安排、等待和额度中断估计

子代理并行和夜间执行可以改变交付周期，人工参与时间则单独记录。后续用同类任务的实际审查、返工和验收记录校准估计，让工时判断逐步建立在项目经验上。

这段实践留下两个持续改进的问题：怎样及时发现 AI 快速生成中悄然改变的业务细节，以及怎样把审查、纠偏和验证的投入纳入工时估计。

9. 我的收获与下一步

这次实践让我形成了更完整的 AI 协作研发方法：由我明确业务目标、判断方案和控制变更范围，借助 AI 与工具完成调查、实现和核查，再通过实际验收推进交付。

离线功能剥离尤其说明了这一点。面对业务变化，我需要保留最新在线成果、撤下不成熟能力，并在执行中不断发现和纠正偏差。AI 扩大了可处理的工作范围，夜间执行延长了推进时间，最终仍需要把每一步收敛到明确的业务结果。

当前 AI 还不能一键完成这类复杂工程。我的收获是在试错中积累判断，把错误整理为审查要点，把有效做法转为工具和资料，并持续关注、验证新的技术。

以接手时的工程基础和需要覆盖的工作范围，我判断，完全依靠人工逐项完成，很难在同等周期推进这些工作。后续我会继续保留任务、投入与验收记录，用实际比较选择更合适的模型和协作方式，把资源更多地用于有效实现、必要审查和可复用建设。