我第一次被客户催交付时，才知道“会写代码”不等于能交付
上周二晚上十点，我在杭州的出租屋里改一个客户官网：页面能打开，但按钮点了没反应。我让 AI 工具帮忙找原因，它很快给出一堆建议；我复制、测试、再改，折腾到凌晨一点，交付前还是漏了一个手机端问题。以前我以为自动化就是“让 AI 多做一点”，后来才明白，真正省时间的不是多生成答案，而是少让人替工具做重复核对。
斯坦福的课程改法，核心是让人参与得更像“对话”
Mihail Eric 在斯坦福教《The Modern Software Developer》，同时负责 Monaco 的 AI 团队。他把课程作业从“让 AI 写完一个功能”改成“让 AI 帮忙实现，再由项目维护者审核代码”。重点不是代码漂亮了，而是人要继续问：维护者是否真的想要这个功能？现有逻辑为什么这样写？这次修改还可能影响什么？我也用过类似方法：我让 AI 先说明改动会碰到哪些文件，再逐条确认，最后自己跑一遍关键流程。对我这种非技术背景的创业者，这比一上来就要求自己读懂每行代码更实际。
今天照着做，成本很低：0 元，大约 90 分钟，门槛是能说清业务目标
钱：不用买新工具，现有聊天式 AI 工具即可，预算 0 元。时间：约 90 分钟，其中 20 分钟整理需求，45 分钟让 AI 解释影响范围，25 分钟人工验证。第一步：打开你常用的 AI 工具，新建一个对话，输入“我准备修改【功能名称】；先不要写代码，请列出需要确认的需求、受影响的文件和验收步骤”。如果工具不会读你的项目文件，就先把相关页面或代码贴进去，别一上来把整个文件夹都丢进去。
按你现在的阶段，我会这样安排
如果你刚起步、主要做内容或手工服务，我会先拿一个低风险的小任务试，不必碰核心系统；现在不试也没事，先把客户需求写清楚更划算。如果你有 1-2 个稳定客户，我会用这套“需求—影响范围—验收”对话，让 AI 先做初稿，再请你信任的人或开发者复核；如果对方说不清“改完怎么算完成”，先别急着自动化。如果你在扩规模、团队里已有开发者，我会把它变成固定复盘：每次改动都留下需求、风险和验收记录，再决定哪些环节值得交给工具。这里不是让所有人学编程，而是让 AI 输出更容易被检查、被交付、被复盘。