你发现没有现在聊AI Coding的人已经分成两种一种还在问“AI到底能不能正经写代码”另一种已经把项目从需求到上线全跑完了。我属于后者。过去两个月我用一套自己总结的工作流跑通了一个真实项目这套工作流我给它起了个名字叫“即先AI Coding”。这里的“即先”不是某个工具的名字而是一种工作方式不是等自己想明白再动手也不是把AI当自动补全用而是每一个环节都先让AI交出一版初稿——需求分析稿、技术方案稿、代码稿、测试稿、部署稿——然后由我来做评审和裁决。如果你把“AI全搞定”理解成“全程无人看管”那多半会翻车正确理解是“全流程有人把关、由AI垫底执行”。下面我会用一个会议室预约系统的例子把我实际用到的Prompt、数据模型、排障过程和踩坑点都摊开讲适合正在试用AI编程工具的独立开发者、全栈工程师以及想提升小团队交付效率的团队负责人。1. AI Coding不是自动补全是一整个“虚拟开发小组”1.1 从“补全下文”到“Agent式干活”早期AI编程工具大家都用过本质是“下一行预测”光标停在那里AI帮你补一个函数名、补一段样板代码。这种用法省事但没有改变开发流程AI更像一个高级输入法。但现在的AI Coding工具已经变了。我常用的方式是给AI一个任务描述它能自己读取项目目录、搜索相关文件、生成改动计划、改完以后自己跑测试再把报错拿回来修。这个形态已经不是“补全”更像是有一个“虚拟开发小组”在你机器上开工。“即先AI Coding”的核心理念也是从这里来的既然AI已经能整包干活那就让它承担“先写第一版”的角色人不再逐行敲基础逻辑而是做需求定义、技术评审和最终验收。1.2 它能干什么不能干什么AI Coding现在的边界在哪里我按自己实际跑项目的经验做了个划分能干的内部管理系统、MVP原型、活动落地页数据报表、后台管理、批量脚本给已有项目补测试用例、修bug、做模块重构生成Dockerfile、CI流水线、部署手册。不建议让它单独干的没有人工review就直接上生产的核心交易链路需要严格审计、强合规、强低延迟的场景完全没人理解业务边界和影响范围的“黑盒交付”。我把AI当成“能力很强、但经验判断不足的实习生”来用。它执行力强可如果方向错了会一本正经地把错的方向执行完。所以人负责“方向感”AI负责“把方向快速变成代码”。这个定位想清楚后后面每一步的工作方式都会顺很多。2. 需求阶段把一句“我想做个会议室预约”变成AI能执行的任务书2.1 让AI先当“需求分析师”而不是急着写代码很多人拿到需求就急着说“帮我写个会议室预约系统”AI会顺着话头猜写出来自然跑偏。我的做法正好相反先让AI把需求结构化成任务书再谈写代码。最初的原始需求只有一句话“我要做一个内部用的会议室预约系统能看到哪些房间空着谁预约了预约了还能取消。”我把这句话原样丢给AI指令是请把下面这段原始需求整理成结构化需求文档。 要求 1. 按“用户故事 / 验收标准 / 隐藏假设”三类输出 2. 用户故事要覆盖普通员工可能的所有操作路径 3. 验收标准必须可以验证不能出现“友好、流畅”这类形容词 4. 最后向我提出至少10个澄清问题帮助我确认边界。AI给的输出比我想象中靠谱关键几则用户故事是这样的作为员工我想查看未来7天所有会议室的空闲时段以便快速锁定可用的会议室。作为员工我想提交一个指定时间段的预约申请以便安排团队会议。作为员工我想取消自己发起的、尚未开始的预约以便释放资源。作为管理员我想查看所有预约记录以便处理异常占用的会议室。验收标准也落地了很多例如“若时间段与已有预约冲突系统应拒绝并提示冲突的预约ID与时间段”“员工只能取消自己创建的预约”“会议室列表为空时展示空状态提示”等等。原来我脑子里只有个大方向的“预约系统”被AI这么一拆忽然清楚多了。2.2 用“反向提问”逼出隐藏假设这个环节是价值最高的。AI提的澄清问题里有几条我一开始完全没想过是否所有员工都能预约所有会议室还是按部门限制预约是否需要管理员审批审批通过前算不算占用预约时间粒度是按小时、30分钟还是15分钟会议超时未结束下一场预约怎么处理取消预约有没有时间限制比如开始前30分钟内不允许取消这些就是典型的“隐藏假设”。如果跳过这一轮直接写代码后面至少要返工两三次。我挨个回答了之后又让AI根据答案生成一个里程碑式的迭代计划M1会议室列表 空闲查询 预约 取消先跑通主流程。M2预约冲突校验 管理员审批流 预约记录管理。M3导入公司组织架构、按部门控制权限、会议室状态看板。到这里一个可以执行的“任务书”就有了。我把它存成项目根目录的REQUIREMENTS.md后面每一轮开发开始前都把对应段的验收标准回贴给AI确保它不会在执行过程中自己加戏。3. 技术选型与数据建模让AI先出方案人只做裁决3.1 让AI做“技术选型报告”需求清楚了下一步是技术选型。我的原则是不要让AI直接拍脑袋给答案而是先给它约束条件让它产出可对比的方案再做裁决。我当时给的约束是这样的我要开发一个公司内网用的会议室预约系统。 约束条件 1. 团队熟悉Python不引入Java/Go 2. 预估用户量100人以内不需要高并发 3. 交付周期两周代码要容易维护 4. 部署在内网服务器不希望依赖外部云服务 5. 需要数据库存预约记录。 请给出3个技术栈组合输出一张对比表包含开发效率、部署复杂度、扩展性、维护成本、是否适合本场景。最后给出你的推荐和理由。AI给的对比表大致如下方案技术栈开发效率部署复杂度扩展性适合场景AFastAPI SQLite高极低低小型内网工具BFastAPI PostgreSQL高中中长期演进的内网业务CDjango PostgreSQL中高中中需要内建后台管理DFlask MySQL中中低旧团队迁移场景我最后选了方案B理由很实际SQLite确实部署最简单但预约数据有强一致性要求而且后续大概率要扩展统计报表PostgreSQL能省掉很多坑。这一步的价值在于AI把备选项、成本和权衡一次性摆在了桌面上“拍板”这件事仍由人来做。3.2 数据模型先画出来再让AI当评委技术栈定了我让AI按照REQUIREMENTS.md里的验收标准先设计数据模型不急着写业务接口。它给的表结构非常直接核心就三张表CREATE TABLE rooms ( id SERIAL PRIMARY KEY, name VARCHAR(100) NOT NULL, capacity INT NOT NULL, location VARCHAR(200), has_projector BOOLEAN DEFAULT FALSE, is_active BOOLEAN DEFAULT TRUE ); CREATE TABLE users ( id SERIAL PRIMARY KEY, email VARCHAR(255) UNIQUE NOT NULL, name VARCHAR(100) NOT NULL, department VARCHAR(100), role VARCHAR(20) DEFAULT employee ); CREATE TABLE bookings ( id SERIAL PRIMARY KEY, room_id INT NOT NULL REFERENCES rooms(id), user_id INT NOT NULL REFERENCES users(id), start_time TIMESTAMP NOT NULL, end_time TIMESTAMP NOT NULL, status VARCHAR(20) DEFAULT pending, created_at TIMESTAMP DEFAULT NOW() );三张表其实已经能覆盖核心流程。但让AI当评委时它又抛出了几个边界问题跨天预约怎么处理start_time和end_time是允许跨天还是按天分拆冲突检测要不要考虑“某预约结束时间等于另一预约开始时间”这种情况这些问题直接影响了后面check_booking_conflict函数的实现。数据建模这步没省掉直接让后面编码阶段少走了很多弯路。4. 编码闭环一条四段式Prompt把我从反复改代码里解放出来4.1 目标、约束、交付物、验收四段缺一不可编码阶段最常见的错误是把需求说得太模糊比如“帮我写个接口检测会议室时间冲突”。AI跑出来的代码十有八九只是简单查询边界根本没处理。我后来固定下来一套四段式Prompt模板用了很久效果很稳目标在 booking_service.py 中新增一个函数 check_booking_conflict(room_id, start_time, end_time, exclude_booking_idNone)。 约束 - 项目使用 FastAPI SQLAlchemy 2.0ORM模型已存在 - 时间类型为 datetime - 调用方需要在冲突时拿到冲突预约的ID列表而不是只返回布尔值 - 不允许全表加载到内存再判断必须用数据库查询解决。 交付物函数代码 最小单元测试文件 tests/test_booking_conflict.py测试数据用简单工厂构造。 验收运行 pytest tests/test_booking_conflict.py -q 全部通过。同样的需求改造前和改造后AI的行为差别非常大。改造前它可能给你一个SELECT * FROM bookings WHERE ...然后自己慢慢过滤的把法这在数据量小的时候没问题但本质上是逃避数据库设计。改造后它知道要用区间重叠条件更贴近生产环境。4.2 给AI建一套“项目记忆”AI的上下文窗口再大也有限一个新会话开始后它并不会记住你昨天聊过的所有内容。我的做法是在项目根目录维护几个固定文件PROJECT_CONTEXT.md记录技术栈、目录结构、启动命令、关键约定REQUIREMENTS.md记录需求文档、用户故事、验收标准CODE_STYLE.md记录命名规范、错误处理方式、日志风格DEBUG_LOG.md记录历史bug的原因和修复方案。每次新开会话我做的第一件事是让AI读取这四个文件再开始干活。成本很低但AI给出的代码风格会空前一致。有一次我忘了做这步结果AI在同一个文件里一会儿用save()一会儿用insert()命名也是create_booking和add_new_booking混着来非常痛苦。4.3 让AI先行代码审查代码写完之后AI的活还没完。每次提交前我会把Diff整个丢给它要求它按四个维度找问题请审查下面这段diff按这四类问题输出 1. bug风险逻辑错误、边界条件没覆盖 2. 安全性SQL注入、权限绕过、敏感信息泄漏 3. 可维护性命名混乱、重复代码、职责不清 4. 性能问题不必要的N1查询、内存占用过大。有一次它抓出了一个特别隐蔽的问题我的预约取消接口只判断了user_id和预约信息是否匹配但没有判断预约状态是否为pending或confirmed。如果预约已经开始或者已经结束员工依然能“取消”这在业务上是不允许的。这种细节让我自己review还真不一定能在第一时间发现。5. 测试与调试AI写完的bug让AI自己修5.1 “AI生成测试用例”是性价比最高的一件事很多开发者自己写业务代码还行一提写测试就头大。AI恰好相反它特别擅长根据函数签名和需求文档生成大而全的测试用例。以check_booking_conflict为例我让它先列出应该覆盖的边界场景它给得很完整完全空闲时返回空列表开始时间落在已有预约区间内结束时间落在已有预约区间内新预约完全包含已有预约新预约的开始时间等于已有预约的结束时间边界应不冲突新预约的结束时间等于已有预约的开始时间边界应不冲突传入exclude_booking_id时该预约不参与冲突判断。然后我让它按这些场景直接生成pytest参数化测试。结果一次跑通后面改逻辑时回归也特别快。严格来说这比我自己手写测试还省力。5.2 调试的正确姿势把上下文喂够AI写完代码测试跑挂很正常。但很多人调试时的姿势是错的就甩一句“运行报错了帮我看看”。AI看不到你的运行环境只能猜。我的做法是把这几样东西一起喂给它运行 pytest tests/test_booking_conflict.py -q 后test_overlap_start 失败。 报错信息 FAILURES tests/test_booking_conflict.py::test_overlap_start - AssertionError: assert [] [1] 相关代码在 booking_service.py 第42-60行 [把代码贴进来] 调用链是router - booking_service.check_booking_conflict - db.query(Booking). 我怀疑是时间比较的方向写反了但不确定。请先分析可能原因再给最小修复补丁。按这种方式AI基本都能定位到问题。实测下来AI最擅长修的bug是接口参数不匹配、依赖升级后的API变更、语法错误、组件状态不同步这类“可机械排查”的问题最怕的是“需求理解本身就错了”导致的bug——这种它改来改去反而会把代码改得更乱。遇到后一种我的建议是回到需求层对齐而不是在代码层死磕。5.3 用DEBUG_LOG.md沉淀历史问题跑完一个项目后DEBUG_LOG.md已经积累了不少案例。比如QASQLAlchemy连接池未释放导致内存持续增长前端日期字符串传成了UTC格式后端没做时区转换钉钉机器人回调签名校验失败原因是消息体用JSON字符串化了两遍。这些经验沉淀下来再遇到类似问题直接把DEBUG_LOG.md丢给AI当参考它的修复建议会准确很多。这也是“即先AI Coding”里面容易被忽略但很关键的一环AI的长期记忆是靠这些项目文件实现的不是靠对话历史。6. 部署上线AI能写出能跑的部署文件但验收线要握在手里6.1 从“编写”Dockerfile到“审查”Dockerfile部署这块我基本不手写部署文件了。让AI根据项目技术栈生成多阶段Dockerfile外加docker-compose编排效率高得离谱。前端Vite构建产物直接打进后端静态目录一条命令就能启动整个服务。一个典型的多阶段Dockerfile长这样FROM node:20-alpine AS frontend-builder WORKDIR /app COPY frontend/package*.json ./ RUN npm ci COPY frontend/ ./ RUN npm run build FROM python:3.12-slim WORKDIR /app COPY backend/requirements.txt ./ RUN pip install -r requirements.txt COPY --fromfrontend-builder /app/frontend/dist ./static COPY backend/ ./ CMD [uvicorn, app.main:app, --host, 0.0.0.0, --port, 8000]再用docker-compose把PostgreSQL编排进去services: db: image: postgres:16-alpine env_file: .env healthcheck: test: [CMD-SHELL, pg_isready -U $POSTGRES_USER] interval: 5s timeout: 3s retries: 5 volumes: - pgdata:/var/lib/postgresql/data api: build: . ports: - 8000:8000 depends_on: db: condition: service_healthy volumes: - ./data:/app/data volumes: pgdata:这类文件AI只要读一遍PROJECT_CONTEXT.md基本就能一次写对。我真正要花时间的地方反而在“验收”和“排障”。6.2 上线前必须人工盯的三个验收项AI写部署文件有一个特点它能保证“能启动”但不保证“能上线”。我在这个项目里总结出三个必须人工把关的验收项第一敏感信息扫描。AI有时候会把数据库地址、密钥、Token硬编码写进配置模板里甚至顺手提交进代码库。上线前我用一段扫描脚本检查所有env、配置文件和提交历史任何形如AK/SK、password、token的痕迹都不能放过。第二数据库迁移确认。AI写的初始化表结构只是“当前可用”但后面每次改表结构都必须有迁移记录。我让AI生成了Alembic迁移目录并要求每次数据模型变更必须同时产出对应迁移脚本否则不merge。这样线上数据结构和代码版本才能对得上。第三健康检查与自恢复。容器崩了能不能自动重启数据库暂时连不上API是直接崩还是重试这些如果没有配置光有Dockerfile也是白搭。我会要求AI把healthcheck、restart策略、日志落盘一并配置好再谈上线。6.3 一个真实排障容器内存持续走高这个项目上线后遇到过一个典型问题服务跑两天容器内存一路涨到接近上限重启之后又正常周而复始。我没有直接去看代码而是先把本地的线程dump和内存统计丢给AI限定范围让它排查。AI定位到SQLAlchemy的连接池没有正确释放。每次请求都会创建新的数据库连接连接池默认行为又没有回收策略长期运行自然越来越慢。修复方式就是在数据库引擎里加上engine create_engine( DATABASE_URL, pool_size5, max_overflow10, pool_pre_pingTrue, pool_recycle3600 )同时FastAPI在shutdown事件里调用engine.dispose()。改完以后内存曲线平稳多了。这种问题在没有AI辅助时花半天都可能找不到现在把日志和数据一贴它很快能给出方向。这进一步验证了我那套“先让它写、我再来查”的工作流是成立的。7. 单独说说两个话题踩过的坑和面试里怎么聊AI Coding7.1 六个最常见的坑以及怎么绕开AI编程远不是“全程躺赢”我也踩过不少坑。整理一份最常见的一条条说清楚现象根因对策AI用了不存在的API代码跑不起来模型记住了旧版SDK或自己“编造”方法明确要求它“只使用项目依赖中已安装的包”并让它自查版本对话长了以后开始乱改无关代码上下文窗口里的约束失效新开会话重新加载项目记忆文件拆小任务无意识删掉“看起来没用”的样式或函数对任务理解过窄让它先输出改动计划再手动确认改动范围需求变更后被要求直接改数据模型忽略数据迁移约束增量变更每次先出迁移脚本再动表结构生成的代码里出现硬编码密钥模型从示例中复制提交前扫描所有敏感字段AI自己写测试自己也通过测试和实现同源缺陷引入少量变异测试思路让它故意改错几处再跑这些坑基本属于“流程可以规避”的类型。只要每一步都保留人工验收问题不会被带到生产环境。7.2 面试被问AI Coding怎么展开回答最近“AI Coding答题思路”在技术圈聊得很多我也被几个朋友问过面试该怎么讲。我的建议很简单不要背概念用真实项目经验展开。一个稳妥的叙事框架是项目背景什么业务、什么技术栈、多大规模、交付周期多长我的用法需求分析、技术选型、编码、测试、部署每个环节AI具体承担了什么效率对比相同类型的功能以前大概要多久现在要多久风险规避设置哪些验收关卡如何防止AI乱写乱改踩坑与复盘挑一个具体问题讲清楚现象、定位思路和修复方案。比如你可以这样讲“我在一个预约系统里让AI负责冲突检测的编码我提供四段式Prompt它生成实现和测试。发现边界用例没覆盖后我让它先列举所有边界场景再写用例最终把问题收敛了。”这一句话既体现了你会用AI也体现了你会驾驭AI。面试官真正想看的其实就这件事。写在最后的一点个人体会整套流程跑下来我最深的感受是AI Coding带来的不是“不用写代码”而是“把写代码这件事的起点变高了”。过去完成一个功能最耗时间的往往是从空白文件到第一版能跑的代码现在这段路AI走得比人快得多真正拉开差距的反而是需求分析、技术评审、验收把关这些“人在回路”里的事。所以我现在的态度很明确大胆用但永远保留一个能看懂全部代码的人。AI负责把“想清楚的事”快速变成第一版人负责把“还没想清楚的事”想清楚。如果你想完整跑一遍这套“即先AI Coding”工作流我的建议是别从大项目开始。找一个两周内能交付的内部小工具严格按照需求拆解、方案裁决、四段式Prompt、测试验收、部署上线这个顺序走一遍。走完以后你会形成自己的节奏也会比我更快找到这套方法里哪些环节最值得你投入时间。