# 这一年，我是怎么和 AI 一起做开发的：逐页讲稿 本地演示稿0.2.1 · 2026-10-16 · 对应17页HTML演示 ## 开场 ### 第01页：这一年，我是怎么和 AI 一起做开发的 今天想分享的是，我怎样与 Agent 一起推进开发任务。这里的 Agent，是能够阅读项目、修改文件、调用工具，并根据运行结果继续工作的助手。 之前，我通常先把产品需求转成技术方案，拆好任务，补上参考代码和注意事项，再让 AI 实现，最后自己检查代码、测试和验收。现在我更常从方案还没想清楚的时候就和它讨论，再一起列计划、推进和验证。以前也会一起讨论，只是现在更常这样做。今天先简单回顾，再展开今年的实践。这里讲的是个人经验，后面的例子经过概括，或明确设为虚构需求。 ## 01 · 协作方式是怎样变化的 从辅助写代码，到一起讨论和推进任务。 ### 第02页：先回顾：四种协作模式 在我的使用过程中，最初是让模型回答 API 问题、生成函数或类型，再由我放回项目。后来编辑器补全能利用相邻代码，帮助我补充样板结构，但仍由我决定写什么、放在哪里。 后来，工具能阅读多个文件，我开始和它一起定位问题、修改实现。再往后，我会把一项开发工作拆成技术任务，写好方案，指明参考文件和限制，交给它实现，最后自己检查代码和验收。这时交给它的，已经是经过整理的开发任务。它也会帮我分析和列计划，我仍要确认关键选择。 这几种模式没有相互消失。写局部代码时仍可以用补全，跨模块任务可以交给 Agent。理解需求、补充背景和验收结果，也一直是人需要承担的工作。 ### 第03页：今年：先看任务，再决定怎么做 之前让 AI 做开发，我会先准备好任务说明、参考文件和注意事项。我也试过把每个步骤都规定好：先写规格，再按阶段执行。今年我没有那么常用整套固定流程了。有些问题，我会先和它聊清楚，再决定接下来怎么做。 比如只改一处文案，改完检查就可以了。遇到业务上还没想清楚的问题，我会先让它看代码、列出疑问，我们一起讨论，确认以后再动手。如果任务要做很久，或者改错了影响比较大，我才会把计划写细一点，约好哪些地方要停下来让我看、每一步做到什么程度算完成。 我现在会多问一句：这件事还缺什么？缺业务信息，就先补信息；缺验证办法，就先准备测试。要让它连续做下去，还得提前想好出了问题看哪里、中断以后怎么接着做。后面几页会具体展开这些做法。 ### 第04页：复杂任务的三个阶段 碰到复杂一点的需求，我一般先和 AI 把问题聊清楚：到底要改什么，哪些业务条件还没确认，方案有没有做得太复杂。确定下来以后，就把这些选择和理由写进技术方案。 接着，我会让它根据方案列执行计划，写清楚先做什么、怎么检查、做到什么程度算完成。我看过计划，确认没问题，再让它往下做。前面的方案已经讨论清楚，这一步就不用把需求重新聊一遍了。 这几步可以在同一个对话里做，也可以换一个对话继续。换的时候，把方案和计划带过去，说明已经做到哪里、还有什么问题没解决，让它知道该从哪里接着做。如果做着做着发现方案不合适，也可以回来改。小任务就不用把每一步都分开。 ## 02 · 先把需求和方案想清楚 把业务条件说清楚，决定这次需要做到什么程度。 ### 第05页：先对齐代码里看不到的条件 用一个完全虚构的需求说明：为资料整理工具增加批量导入功能。只写这句话，还不足以确定实现。文件格式、每批数量、重复资料的规则和失败后的重试方式，都会影响设计。 我会先让 Agent 只读探索已有实现和文档，说明现有行为、需要改变的部分及不确定假设，再集中澄清会显著影响设计的问题。人补充的是业务事实，而不只是指示它改哪个文件。 拿失败重试来说。假设这是给小团队的运营人员用的工具，他们熟悉资料格式，也能接受失败后手动处理。我会考虑先列出成功数、失败原因，提供可下载的失败清单，让他们修正后只补传失败项。使用者需要多操作几步，但可以先不做后台自动重试和复杂的恢复界面，减少开发和维护工作。 如果换成面向大量普通用户的产品，很多人第一次使用，而产品又希望他们尽量少操作，我就会考虑保留已完成的结果，显示进度，提供一键重试失败项的入口。服务暂时不可用，可以自动重试几次；资料内容有问题，就提示用户修正。重试时，也要避免把已经成功的资料重复导入。 方案里要把这些理由留下来：现在由熟悉流程的运营人员手动补传，等到需要让更多用户自助完成，再重新考虑重试体验。能简化多少，要看使用人数、熟悉程度、失败频率和出错的代价。即使是内部工具，数据丢失或重复写入会造成严重后果时，也得把可靠性要求单独确认清楚。 ### 第06页：架构审查，也包括做减法 还是这个导入功能。假设我自己在本地用，每次几十条，失败了可以手动再来一次，那么按顺序处理、告诉我哪几条失败、让我只重试失败项，就够用了。这里不需要额外设计后台调度。 后面如果真有新的要求，再补对应的能力。比如关闭页面以后也要继续导入，就要考虑让任务在后台执行；中断后要接着做，就要保存任务进度。需要补什么，由具体要求决定，人数或数据量增加本身，也不代表一定要换一套复杂架构。 我看 AI 的方案时，会先问这些设计是为了解决什么问题。如果它加了当前用不上的功能，我会把这版的范围说清楚，让它删掉。失败要有提示，已经成功的资料也别重复导入；这些基本处理保留，其他功能等有明确要求时再做。 ## 03 · 把任务推进到完成 确认计划、持续执行，在沟通与验证中把任务做完。 ### 第07页：计划要写出完成条件 技术方案说明实现思路，执行计划还要说明先做什么、依赖什么、怎样判断完成。导入需求可以拆成文件解析、导入处理、结果提示和回归检查。每一步都有完成条件与证据位置。 此外还要定义整体验收：用约定样例完成导入，检查有效资料的保存结果，并确认重复和无效记录按约定处理。局部步骤完成，不能自动等同于整个任务完成。 我会先检查这份计划，再开始执行。哪些检查可在本地完成、哪些依赖外部环境或人工确认，也要提前写清楚。完整的提示词保留在文字材料里，现场重点看这些完成条件。 ### 第08页：让执行可以继续，也可以恢复 执行阶段，计划保存目标和完成条件，进度文件保存状态。我会让 Agent 记录已经完成的工作、证据在哪里、还缺什么，以及下一步是什么。这两类信息分开维护，便于发现目标变化。 如果环境中断或切换会话，记录里应留下中断前的状态、已通过的检查和未完成的验证。新会话先核对代码、环境与记录是否一致，再继续推进，不能只照着旧进度往下做。 需要我介入时，Agent 应说明具体阻塞、可选处理和需要我作出的决定。文件传递确认过的约定，对话处理新问题。完成报告则需要对应阶段和整个任务的验收条件。 ### 第09页：像和同事一样，把问题说清楚 现在做需求时，我更愿意把 Agent 看作一起开发的同事。还有业务背景没说清，就补给它；对方案有不同想法，就拿出来讨论；实现和预期不一样，就具体指出来。我也会让它说说自己的判断，有疑问就提出来。 比如还是这个导入工具，我会这样说：这是给熟悉流程的运营人员用的，当前可以接受手动补传。先保留失败清单和原因，自动重试这次先不做。这样它能知道哪些是业务条件、哪些是已经决定的范围。 如果它还是加了自动重试，我会让它对照方案，删掉超出这次范围的部分。如果它认为这项功能有必要，也可以先说清楚要解决什么问题，我们再决定是否保留。讨论有了结果，就把理由补回方案里。 实现真的出了问题，就把复现步骤、预期和实际结果说明白，让它检查原因、修复并验证。我们再一起看代码差异和运行结果，确认问题有没有解决。 ### 第10页：开发时用 Mock，完成后再联调 做页面开发时，我会先把登录、接口这些外部依赖换成 Mock，准备好成功、失败和超时的返回。这样 Agent 改完代码，就能在本地运行、看页面、检查结果，再接着改，不用每次都等真实服务和测试账号。 比如前面那个导入页面，我可以让 Mock 固定返回几条成功、几条失败的数据，看看成功数和失败清单显示得对不对。要比较界面改动，就用同一份数据、相同的页面状态看前后截图，哪里没对齐会比较容易发现。 等页面功能做好，再切到联调环境，接上真实登录和接口，看看接口有没有按约定返回、数据有没有真正保存下来、整条流程能不能走完。如果真实服务的行为和 Mock 不一致，就按实际接口约定调整实现和 Mock，再验证。 具体查到什么程度，也要看改了什么。只改一处文案，我会看看显示对不对、有没有挤坏布局。如果改了保存逻辑，就要实际保存一次、刷新后再看，也试试原来的数据还能不能正常读取。 ## 04 · 把经验留在项目里 积累开发资产和项目知识，让后续任务有现成的准备。 ### 第11页：把开发准备留在项目里，后面接着用 开发时准备好的 Mock、测试数据、启动和验证命令，我会留在项目里，作为长期开发资产来维护。这也是我在项目里做 Harness Engineering 的一部分：让后续的 Agent 有现成的环境和做法可以复用。 比如导入功能开发完，可以把有效资料、重复资料和格式错误的样例保存下来，和 Mock、测试脚本放在约定的位置，再说明怎么运行。下次继续改导入功能，Agent 就能沿用这些样例检查，不用让人重新准备数据、重新解释测试方法。 排查和恢复的方法也一起留下：日志去哪里看，失败后怎样重置数据、重启服务，临时改动怎么清理。多个任务同时做时，目录、端口和浏览器会话怎么区分，也可以整理成脚本或操作说明。 这些材料要跟着实现一起更新。接口改了，就检查 Mock 和测试数据；启动方式变了，就更新脚本和说明。长期积累下来，后面的开发可以从现成的准备开始，人也少重复补充背景、带着 Agent 重新走一遍流程。 ### 第12页：让 Agent 按需找到项目知识 前面的准备可以用两个概念概括。上下文工程关注去哪里找到正确的信息。Harness Engineering 关注执行、验证、观测和恢复条件。概念本身不复杂，重点是项目里是否有这些可用入口。 我倾向于把 AGENTS.md 这样的入口写得简短，说明基本约定并指向相关资料。当前任务的方案、进度和截图，与跨任务有效的业务规则、架构理由和运行指南分开维护。Agent 按任务读取。 技能可以理解为按场景调用的操作说明。重复的操作能整理成脚本或技能，但读取了资料并不代表已经正确遵循，仍要看实现和验证结果。 ### 第13页：任务结束后，提炼仍然有效的知识 不是每份任务计划都要成为永久规则。临时模拟、调试细节和当前进度可以留在任务目录。跨任务仍然有效的测试命令、环境前提和设计理由，再提炼到长期文档。 优先记录代码外部的约束、每次推导成本较高的模块关系，以及已有设计的理由。局部代码直接能看懂、变化很快或能自动生成的信息，可以通过代码和工具查询。 文档还需要持续核对。测试命令变化，要更新指南和技能；兼容分支删除，要检查旧说明是否仍在要求使用它。任务结束时可以让 Agent 列出需要更新的材料，再由人检查准确性。 ## 05 · 用下来遇到的问题与反思 消息和输出变多、开发加快之后，人的审阅与后续交付怎样跟上。 ### 第14页：消息和输出多了，人还是要逐项看 前面讲了怎么让 Agent 持续工作，用下来还有另一种负担：消息变多了。机器人发进度，Agent 报完成，评审又给反馈。几个任务同时跑，我还得从这些消息里找出哪条真的需要处理。普通更新把注意力占满以后，重要的提醒也更难找。 代码和文档也一样。AI 可以继续生成，我还是得花时间看懂改动、核对依据、决定能不能接受。如果一边审阅，一边又不断启动新任务，等着我看的内容就会继续增加。 我更希望只在需要我作决定、出现阻塞或影响交付时收到通知。普通进度可以集中汇总，详细日志留在任务里，需要排查时再看。代码也按能单独理解和验证的改动交接，说明改了什么、检查了什么、还缺什么。 能并行运行多少 Agent，和我能同时照看多少任务，是两件需要分别考虑的事。下一批任务什么时候开始，也得看看手上还有多少结果没审完。 ### 第15页：发给别人之前，先整理成对方需要的内容 还有一种情况，是把 AI 的整段回答直接发给对接的人。看起来材料很多，但对方读完还不知道结论是什么、哪些内容已经确认、希望他做什么。生成和转发很快，理解、筛选和核对的工作却留给了接收方。 这里说的 AI Slop，指的是没有经过核对和取舍、看起来完整却让人难以使用的输出。用了 AI 以后，我自己发出去的内容也要先看过，说明我认可什么、依据在哪里，哪些还只是待确认的想法。 比如需要别人确认方案，我会先说清楚要他决定哪件事，我建议怎么选、为什么这样选。支持判断的代码、测试结果和资料可以附上，原始过程也可以保留供回查。对方先拿到需要处理的问题，再按需要查看细节。 代码交接也是如此。不能只给出一大段改动，再让审查的人自己拼出需求、设计和验证过程。我需要先把这些说明整理好，保留必要细节，也删掉与这次判断无关的内容。 ### 第16页：代码写得快，评审和测试仍要排期 开发快了以后，评审和测试并不会自动跟着变快。实现做完以后，还要安排代码评审、准备测试环境，完成回归和业务确认。只看开发这一步，很容易忽略任务还要走多久才能交付。 前面讲的 Mock，能让开发阶段在本地反复修改和检查。接入真实服务以后，接口配合、数据保存、业务回归仍要确认；团队里谁来做、什么时候有环境，也需要提前安排。 如果不停增加开发中的任务，完成的改动又集中交给同一批人评审和测试，后面就会积压。我会更关注能不能按可验收的部分交接，把测试范围、数据和运行方式准备好，也留时间处理反馈。 讨论效率时，我想看的是从需求开始到最终交付的过程：开发用了多久，评审和测试等了多久，又有多少改动需要返工。这些环节一起改善，才是在减少整个任务花掉的时间。 ## 回看这一年 回顾一起做事的方式，也把审阅、沟通和交付放进考虑。 ### 第17页：把任务做完，也把结果交代清楚 回看这一年，我以前更常先想好方案、拆好任务，再交给 AI 实现。现在，我会更早和它讨论，把计划、执行和验证接起来。业务条件怎么理解，方案要做到多复杂，最后的结果能不能接受，我仍然要参与判断。 用得更多以后，我也开始关注另一部分工作：消息会不会太多，输出能不能让人看懂，评审和测试能不能接着往下做。让 Agent 多跑任务的同时，也要给人留下理解、判断和反馈的时间。 所以我希望每次合作结束时，功能实现了，结果和依据也交代清楚；项目里还能留下可复用的脚本、数据和经验。下一次开发就从这些准备继续。今天就分享到这里，欢迎聊聊你们在实际开发中遇到的问题。