# 这一年，我是怎么和 AI 一起做开发的 分享稿 0.2.1 · 2026-10-16 现在处理一个复杂需求时，我越来越常把工作分成几段：先与 Agent 讨论业务和技术方案，再把方案变成带验收目标的计划，最后让它按计划持续执行。我在需要业务判断时介入，并在结束后检查结果。几个阶段可以放在不同会话里，已经确认的目标和决策通过文件传递。 这种做法是从问答、代码补全和任务委派逐步发展过来的。先用一小段回顾说明这条路径，再谈今年我怎样组织更长的任务，以及哪些准备可以在项目中反复使用。即使没有听过之前的分享，也可以从这里开始。 ## 先回顾：从生成代码片段，到委派完整任务 在我的使用过程中，人和 AI 的配合大致经历了四种模式。 最初是问答和代码片段。我描述问题，让模型解释一个 API、生成类型或写一个函数，再把结果放回项目。人负责选择材料、整合代码和检查效果，模型处理的是提供给它的局部问题。 接下来是编辑器中的代码补全。工具能利用当前文件里的类型、命名和已有写法，继续补充重复结构。例如，在一个状态管理模块里，根据相邻代码补齐状态定义和读写方法。人仍然决定写什么、放在哪里，AI 参与了输入代码的过程。 再往后是项目内协作。我开始让工具阅读多个文件、理解调用关系、定位问题，并一起讨论和修改实现。交互从“帮我写这段代码”，扩大到“这个问题为什么发生，应该改哪些地方”。 随后是完整任务委派。这里的 Agent，指能够读取项目、修改文件、调用工具，并根据运行结果继续工作的助手。我提供目标、背景和边界，它推进实现与检查，我审查方案和结果。交互的单位开始变成一个需求或一项排障任务。 [查看模式回顾图解](index.html#slide-2) 图 1：我的使用路径与今年关注的实践。这些模式仍会同时存在：写局部代码时可以用补全，处理跨模块需求时可以委派任务。 在完整任务委派的早期，我已经会提供任务说明、参考文件和限制条件，也尝试过先写详细规格、再严格按阶段执行的工作流。今年进一步变化的，是如何按任务选择这些步骤，以及如何让项目本身提供持续执行所需的信息和环境。 ## 今年的变化：按任务组合能力，逐步完善执行条件 在我的使用中，随着所用模型和工具能力增强，部分任务可以减少固定的规划步骤。我更常把调研、方案讨论、计划、编码、评审和验证看作可组合的能力，根据当前任务选用。这是个人实践中的变化，不能单独归因于模型能力；项目资料和验证条件也同时在改进。 范围明确、容易回退的小修改，可以直接执行并检查结果。需求包含业务歧义时，先讨论方案。涉及多个模块、需要跨会话推进，或者错误后果较大时，再增加执行计划、阶段验收和人工检查。 决定采用哪些步骤时，我会检查信息是否充分、关键取舍是否确认、验证方式是否可靠，以及出错后能否恢复。这些条件分别影响调研、方案审查、验收和进度记录的安排。 同时，一些原本每次都要说的要求可以进入项目。业务边界和设计理由写入文档，重复的操作整理为脚本或技能，完成条件对应到测试和检查入口。技能可以理解为一份按场景调用的操作说明，告诉 Agent 如何使用相关工具或执行一类任务。 这里涉及两个常见概念。上下文工程关注 Agent 去哪里找到正确的信息；Harness Engineering 关注它怎样在约定的范围内执行、观察结果、验证和恢复。对实际项目来说，可以先建设清楚的资料入口、可运行的检查、日志和恢复方式，再按需要补充。 下面从任务如何交接、人类在哪里判断，以及项目怎样支持执行三个方面说明。 ## 把复杂任务分成对齐、计划和执行三个阶段 三个阶段分别处理不同的问题：对齐阶段确定业务和技术方案，计划阶段确定推进顺序与完成条件，执行阶段根据结果继续实施和验证。它们可以在一个会话内完成，也可以通过文件交接到后续会话。 [查看任务阶段图解](index.html#slide-4) 图 2：复杂任务的一种组织方式。阶段之间可以返回修改；小任务可以合并或跳过不必要的规划步骤。 ### 先讨论代码里看不到的业务边界 假设要为一个资料整理工具增加批量导入功能。这是为说明方法设定的虚构需求。开始设计前，需要确认支持的文件格式、单批资料数量、重复内容的处理规则，以及导入失败后如何重试。这些条件尚未明确时，相同的批量导入要求可以对应不同的实现。 这些信息会影响方案，也未必都能从代码里读出来。这个阶段适合先让 Agent 只读探索现状、说明不确定的假设，再由人补充业务事实。 ```text 先只读了解需求、现有实现和相关文档，暂不改代码。 请说明现有行为、需要改变的部分、仍不确定的业务假设， 并提出满足当前需求的最小方案。 对会显著影响设计的歧义集中向我提问，确认后再完善技术方案。 ``` 对齐后的技术方案需要保留选择理由和适用边界。在这个假设中，方案应写明重复资料怎样识别、失败项怎样保留，以及什么规模变化会触发重新设计。后续会话读到这些材料，才能理解已经作出的取舍。 ### 再把方案变成可以验收的计划 方案说明实现思路，执行计划还要说明先做什么、依赖什么、怎样判断完成。 继续以这个虚构的导入需求为例，计划可以分为文件解析、导入处理、结果提示和回归检查。每一步既要有完成条件，也要有证据位置；整个任务还需要一个独立的验收目标，例如用事先约定的样例完成导入，检查有效资料的保存结果，并验证重复内容和无效记录按约定处理。 ```text 根据已确认的技术方案生成执行计划，保存为计划文件。 每个阶段写明目标、依赖、验证方式和完成证据； 另外定义整个任务的验收目标。 说明哪些检查可以本地完成，哪些依赖外部环境或人工确认。 我检查计划后，再开始执行。 ``` 我近期常把计划放在单独的会话里处理。前面的业务讨论已经写入方案，计划阶段可能只有一两轮。因此，短会话也可能承接复杂任务；复盘时，需要连同前面的方案讨论和后面的执行一起理解。 ### 执行时保留目标、进度和恢复入口 进入执行阶段后，计划保存目标和完成条件，进度文件记录当前状态：已经做了什么、证据在哪里、还缺什么、下一步是什么。两类信息分开维护，便于检查目标有没有改变，也便于恢复工作。 ```text 按计划执行，在已有授权范围内持续完成实施与验证。 用独立进度文件记录已完成项、证据位置、未完成项和下一步。 只有满足阶段及整体验收条件，才能报告任务完成。 需要我介入时，说明具体阻塞、可选处理和需要我作出的决定； 恢复工作前先核对当前代码、环境与进度记录是否一致。 ``` 如果测试环境中断，进度里应该留下中断前的状态、已经通过的检查和未完成的验证。换一个会话继续时，先核对这些记录与当前代码、环境是否一致，再推进下一步。 在多会话任务中，我会明确给出方案和计划的位置，而不要求新会话从聊天历史里猜测目标。文件负责传递已确认的决策，对话用于处理新的问题和取舍。 ## 人类在架构审查中，也需要删减不必要的设计 我仍然经常参与方案阶段。一个原因是业务信息没有完全进入代码和文档；另一个原因是，Agent 可能为尚未确认的需求增加机制。 继续使用前面的虚构需求，再增加一组假设：工具由单人在本地使用，每批导入几十条资料，失败项允许手动重试。在这些条件下，设计分布式任务队列、自动扩容和复杂调度前，应先确认它们解决什么实际问题。按顺序处理并提供明确的结果提示，也可以作为待评估的方案。 如果假设改为多人共享、单批导入大量资料，并且中断后必须自动恢复，方案就需要重新评估并发、持久化和恢复机制。取舍依据是已经确认的使用条件；为未来扩展增加机制时，也要说明触发条件和维护成本。 我的经验是，架构审查有时主要在做减法。人需要说明使用规模、兼容边界和可接受的业务行为，让 Agent 有依据地删减设计；审查也要检查删减后是否遗漏必要的错误处理和约束。 理解错误、错误实现和过度实现仍然需要纠正。处理反馈时，我会先说明问题属于业务信息补充、方案取舍，还是已经发生的实现偏差，再给出对应的修改与验证要求。代码差异、测试和运行结果帮助判断修改是否解决了问题。 ## 把验收条件和运行环境提前准备好 长程任务需要能够检查的目标。委派时除了说明想做什么，还应说明成功标准、允许使用的模拟方式，以及哪些结果必须在真实环境验证。 ### 将阶段检查与整体验收分别写清楚 以一个需要登录的页面功能为例，可以分别检查构建、局部交互、接口集成和完整业务路径。每项检查需要说明对象、环境和预期结果。 外部服务故障时，本地模拟可以验证请求参数和页面状态处理；真实账号的端到端链路仍需在服务恢复后检查。如果允许分阶段交付，可以记录本地阶段已通过、整体验收仍待完成。调整验收范围时，保留调整理由和未覆盖部分。 界面对齐也可以事先约定方法：使用固定数据展示不同状态，对暂时无法访问的接口进行模拟，再保存实际截图与设计稿比较。临时修改需要还原，模拟结果与真实链路结果分别记录。这样，执行者和验收者能够对照同一组条件判断完成情况。 这些检查应针对可能出错的行为。一次文案调整不必套用完整的端到端测试；涉及配置兼容和数据写入时，则需要检查原有数据及持久化结果。 ### 让环境支持反复验证和恢复 如果每轮检查都要重新登录、找测试账号、准备数据或启动服务，持续执行就会反复中断。可以逐步整理可复用的测试入口、固定数据、可切换的本地模拟，以及能够恢复的浏览器会话。 并行任务还需要明确环境归属。例如，不同改动使用独立分支或工作目录，测试服务有可区分的端口，浏览器会话避免相互覆盖。人负责确认操作范围和关键授权，Agent 在约定范围内推进。 失败后也要有可观察的信息。请求日志、错误信息、截图、构建产物和测试输出，可以帮助 Agent 判断问题发生在哪一步。进度记录应说明当前阻塞是实现问题、环境不可用，还是仍需业务决策，并保留恢复入口。 持续的人类介入有时来自这些环境准备。改进协作时，应先看重复操作具体发生在哪里，再决定补脚本、整理资料还是调整执行方式。 ## 把单次任务资料和长期项目知识分开维护 把每次任务的完整讨论都放进长期规则，容易混入过期计划和临时例外。如果资料只留在会话中，下一次任务又需要重新解释。我更倾向于分别维护当前任务资料和跨任务有效的知识。 [查看知识维护图解](index.html#slide-12) 图 3：任务结束后，提炼仍然有效的规则和运行方式；长期文档随实现变化持续核对。 ### 先提供清楚的入口，再按需读取 项目入口可以简短一些，说明基本约定，并指向架构、业务规则、运行指南和相关技能。Agent 根据任务读取需要的材料，避免默认加载全部文档。 长期知识值得优先记录三类内容：代码外部的业务和环境约束；每次都要花较多时间重新推导的模块关系；已有设计的理由与适用条件。容易从局部代码直接看懂、频繁变化或能够自动生成的内容，则可以尽量通过代码和工具查询。 下面是一个可调整的目录示例： ```text AGENTS.md 项目入口、约定和按任务查阅的索引 docs/architecture/ 系统边界与设计理由 docs/domain/ 代码外的业务规则 docs/runbooks/ 运行、测试、排障与恢复方式 docs/decisions/ 仍然有效的取舍及原因 tasks/feature-a/ 本次方案、执行计划、进度和验收证据 ``` 当前任务的模拟脚本、截图和进度保留在任务目录。跨任务仍然适用的测试命令、环境前提和设计理由，再提炼到长期文档。旧计划可以归档，临时例外也应保留适用范围，避免成为下一次任务默认遵循的规则。 ### 用实现和运行结果核对知识 文档说明目标和约定，代码、测试与运行结果帮助检查当前行为。入口是否指向有效资料，命令能否运行，架构描述是否仍与实现一致，都需要维护。 例如，测试入口变化后，应同时更新运行指南和相关技能；一个旧的兼容分支被删除后，也应检查文档是否仍要求使用它。任务完成时，可以让 Agent 列出需要同步更新的长期材料，再由人检查是否准确。 读取了文档并不意味着正确遵循了要求。最终仍要查看实现和验证结果；发现偏差时，再判断是资料过期、入口不清楚，还是执行过程中遗漏了约束。 ## 从一项反复出现的协作问题开始改进 在已有项目中，可以先选择一项反复需要人工处理的问题。每次都解释同一条业务约束，就补充说明及其原因；每次都找不到测试入口，就整理可执行的命令与环境前提；任务切换后经常丢失进度，就把计划、证据和恢复步骤保存下来。 下一次遇到同类任务时，再检查这些准备是否被找到、是否仍然有效，以及还需要人补充什么。先完成一类问题的改进，再决定是否扩展。 对我而言，今年最具体的变化，是更加细致地安排人类判断、Agent 执行与工程材料之间的交接。我仍然需要理解需求、简化方案和验收结果，同时也会把重复的信息与动作整理成文件、工具和验证入口，供后续任务使用。 本文分享个人实践中的变化与可尝试的方法，场景经过脱敏和概括，用于说明判断过程，不表示某个项目的完整执行记录或已测量效果。具体流程需要结合各自项目的风险、资料和验证条件调整。