AI Coding 笔试：思路 + 提示词

阶段 0：准备（笔试开始前）

目标：建立项目目录和初始上下文，避免临时混乱。
操作：新建一个文件夹，创建requirements.md把题目原文粘贴进去。然后打开 AI 对话窗口。

阶段 1：问题定义与风险识别（5 分钟）

目标：不写代码，先让 AI 帮你理解题目、明确交付物、硬约束、风险点。
提示词（复制整段发给 AI）：

先不要写代码，也不要给实现方案。 请根据我提供的题目（见 requirements.md），把任务整理成一份可执行的问题定义。只输出以下内容，每项尽量简短： 1. 最终交付物清单（文件、文档、代码等） 2. 硬约束（环境、依赖、输入输出格式、禁止项等） 3. 隐含要求（从题目描述中推测但未明说的要求） 4. 什么叫"完成"（验收标准，至少 5 条可验证的条件） 5. 最容易翻车的风险点（技术、时间、理解偏差） 要求： - 不确定的地方请明确标记为【待确认】 - 不要做实现假设 - 输出结果请用 markdown 格式保存为 `01_问题定义.md`

做完后：把 AI 的回答保存到01_问题定义.md。如果存在【待确认】项，再追问一次（或根据常识做合理假设，记录下来）。

补充（可选）：产品经理视角需求分析（2~3 分钟）

如果题目偏"应用/工具类"（用户交互、界面、体验），建议在进入技术方案前先跑这一步，帮你避免方向性错误。纯"系统设计/算法类"题目可跳过。

提示词：

现在请你扮演产品经理，不需要写代码。 基于 `requirements.md` 中的题目要求和 `01_问题定义.md` 中的技术约束，请输出一份产品需求分析： 1. 用户使用场景描述（用户是谁，拿这个工具做什么） 2. 核心功能清单（区分必做 / 加分） 3. 功能优先级排序（按用户价值，而非实现难度） 4. 非功能性需求（性能、易用性、错误提示等） 5. 验收标准（用户视角下"能用"的定义） 要求： - 不要涉及技术实现细节 - 用自然语言描述，避免伪代码 - 输出保存为 `01b_产品需求分析.md`

阶段 2：方案选择（5 分钟）

目标：比较 2~3 条技术路线，选最稳的一条（而不是最炫的）。
提示词：

基于刚才的 `01_问题定义.md`，现在不要写代码。 请给我 2~3 条可行的技术方案，每条方案包含： 1. 大致做法（技术栈、模块划分） 2. 主要优点 3. 主要风险 4. 实现复杂度（低/中/高） 5. 可测试性（容易/一般/困难） 最后明确推荐一条方案，并说明为什么不选另外几条。优先考虑稳定交付。 输出保存为 `02_技术方案.md`

注意：如果题目已经限定了语言/框架（例如必须用 Python + FFmpeg），则方案侧重架构设计而非选型。

阶段 3：系统骨架设计（5 分钟）

目标：确定模块、接口、数据结构，为编码打好框架。
提示词：

基于选定的方案（见 `02_技术方案.md`），现在先不要展开实现细节。 请输出一份足够支撑编码开始的系统骨架，至少包括： 1. 模块拆分（每个模块的职责） 2. 目录结构（建议树形图） 3. 核心接口或函数签名（只写名称、参数、返回，不写实现） 4. 关键数据结构（class 或 dict 结构） 5. 主链路时序（从输入到输出的步骤） 6. 权限、隔离和边界（例如临时文件管理、异常兜底） 要求： - 目标是"足够开始编码" - 不要写成冗长的设计文档 - 有边界不稳的地方请明确标出【待细化】 输出保存为 `03_系统骨架.md`

做完后：你手上已经有了三份文档：问题定义、方案、骨架。后续 AI 的每次编码都会参考它们，避免跑偏。

阶段 4：最小可运行闭环（35 分钟）

目标：先跑通一条最短主链路，而不是铺满所有功能。
提示词：

现在开始实现，但只做最小可运行闭环（MVP）。 请先回答： 1. 这个项目的最小可运行闭环是什么？（例如：能读取输入 → 执行一个核心操作 → 产生输出） 2. 建议按什么顺序实现哪些模块？ 3. 哪些东西现在必须做？ 4. 哪些东西现在明确先不做？ 然后围绕这个最小闭环开始写代码。每完成一个文件或一个函数，都给出： - 代码变更说明 - 最短验证方式（命令行如何测试） 要求： - 一次只推进一小步 - 不要提前铺满所有功能 - 如果发现规格有冲突，先指出，不要默默改掉 开始实现，并请将代码文件写入本地目录（按 `03_系统骨架.md` 的结构）。

关键习惯：

• 每让 AI 生成一个文件后，立刻手动运行验证（或要求 AI 给出验证命令）。
• 如果对话变长、AI 开始忘记之前约定，执行"上下文清理"操作（见末尾补充）。
• 主动写交接文档：当对话已超过 ~15 轮，或 AI 开始出现遗忘迹象时，不要让上下文继续膨胀。让 AI 输出一份"交接文档"（已完成功能、当前卡点、下一步 3 件事、关键约束），然后清空上下文从交接文档重新开始。这比硬扛着臃肿的上下文高效得多。

阶段 5：补异常和边界（15 分钟）

目标：主链路跑通后，补齐错误处理、输入校验、边界条件。
提示词：

现在先不要继续堆新功能。 请你切换成"安全审查员 + 质量工程师"的视角，只审查当前代码（忽略尚未实现的加分项）。输出以下内容： 1. 哪些异常路径还没覆盖？（例如：文件不存在、格式错误、磁盘满） 2. 哪些权限边界还没卡住？（例如：读取限制、临时文件清理） 3. 哪些输入还缺校验？（例如：空输入、超长路径、非法字符） 4. 哪些失败场景会让系统行为很差？（例如：崩溃、无提示、死循环） 5. 按优先级（高/中/低）列出今天必须修复的问题，以及可以留作已知限制的问题。 最后给出最小必要修改建议（只修高优先级项）。

做完后：让 AI 按建议修改代码，每改完一个点立刻验证。

阶段 6：验收自检与证据生成（10 分钟）

目标：用证据回答"到底能不能交"，而不是凭感觉。
提示词：

请你切换成 QA 和 Reviewer，不再默认当前代码是对的。 基于 `01_问题定义.md` 和当前实现，做一次系统性自检。输出： 1. 主链路测试用例（至少 3 条，包含输入、预期输出） 2. 关键异常路径测试用例（至少 3 条） 3. 按照以下顺序，逐层列出测试命令并标注预期结果： a. 环境检查（java 版本、依赖包是否齐全） b. 依赖检查（import 是否成功） c. 单元测试（每个模块独立验证） d. 接口/集成测试（模块间调用是否正确） e. 端到端启动测试（完整运行一遍主链路） f. 异常与边界测试（错误输入、极端值） g. 日志检查（是否有未捕获的异常或警告） 4. 哪些地方还没有证据证明它是对的（例如：没测过并发、没测过大文件） 5. 按严重程度列出当前缺口（阻断性 / 严重 / 一般 / 可忽略） 6. 明确结论：现在能不能交？如果不能，卡在哪里？ 输出保存为 `06_验收自检报告.md`

如果结论是"不能交"：针对卡点让 AI 修复，然后重复阶段 6。
如果结论是"能交"：先不急着写文档，进入阶段 6.5。

阶段 6.5：LLM-as-Judge 独立评审与打分迭代（15 分钟）

为何需要：阶段 6 是"自己查自己"，容易有盲区。这一步让 AI 换成独立评审专家身份，从第三方视角打分、找出遗漏点、循环改进直到达标。这是思路 1/2/4 共同强调的关键环节。

目标：获得独立评分 ≥ 90 分后再进入文档交付。

第一步：初次评审

现在请你换个身份。你不再是这个项目的开发者，而是一个独立的技术评审专家。 你将收到以下材料： - 原始题目要求（`requirements.md`） - 问题定义（`01_问题定义.md`） - 当前全部代码和 `06_验收自检报告.md` 请对项目做一次完整的独立评审，输出： 1. 功能完成度评分（0~100 分） - 必做功能覆盖度 - 加分项覆盖度（如有） 2. 代码质量评分（0~100 分） - 结构清晰度 - 错误处理与边界 - 可维护性 3. 测试充分度评分（0~100 分） - 是否有证据支撑每个功能的正确性 - 异常路径覆盖 4. 综合评分（加权平均，满分 100） 5. 按严重程度列出改进建议（阻断 / 严重 / 一般 / 建议） 6. 明确判定：当前是否可以交付？（是 / 否，说明理由） 输出保存为 `06b_独立评审报告.md`

第二步：根据评审修复

根据评审报告中的建议（优先修"阻断"和"严重"级别的），让 AI 逐项修复，每修一项验证一项。

第三步：重新评审（迭代）

请基于最新的代码和修复结果，按照之前的评审标准再做一次独立评审。 对比上一轮评审： - 哪些问题已被修复（列出并确认） - 哪些问题仍然存在（说明原因） - 综合评分变化（从 X 分 → Y 分） 如果评分仍低于 90 分，请指出卡在哪些点。如果剩余时间不足，标注为"已知限制"后进入文档交付。

退出条件：综合评分 ≥ 90 分，或剩余时间不足 15 分钟。如果时间不够迭代，将剩余问题写入KNOWN_LIMITS.md。

阶段 7：交付文档生成（10 分钟）

目标：写出让别人（或判卷人）能直接看懂、跑起来的文档。
提示词：

现在请你切换成交付负责人，不再新增功能，只做最后收口。 请将当前结果整理成一套交付材料，至少包含以下文件： 1. `README.md` —— 包含： - 项目简介 - 环境依赖（精确到版本） - 安装步骤（一行命令） - 运行命令（示例） - 验证方法（输入 → 预期输出） 2. `DESIGN.md` —— 设计说明： - 为什么选择当前方案 - 核心模块与接口 - 关键数据结构 3. `TEST_REPORT.md` —— 测试报告： - 已验证的功能清单（区分必做/加分） - 测试结果汇总表（通过/失败/未测） - 遗留问题与影响范围 4. `KNOWN_LIMITS.md` —— 已知限制与后续优化方向 要求： - 文档必须与真实实现一致，不要编故事 - 用最短路径让别人看懂 - 每个文档都保存为单独文件

最后：人工快速过一遍README.md里的运行命令，确保真的能跑。

补充：遇到卡住或混乱时的急救提示词

使用原则：遇到任何卡住的情况，先用下面的"五类失稳诊断"做第一层判断，定位问题类型后，再选择对应的急救提示词。

五类失稳诊断框架（先定位问题）

先不要继续实现，也不要继续沿着当前思路往下推。 我们现在可能进入了一个失稳状态，请先帮我判断，当前问题更像下面哪一类： 1. 认知失稳 —— 目标、约束、优先级开始变模糊，AI 开始遗忘最初要求 2. 路径失稳 —— 卡在同一条错误思路上反复尝试同一种方法 3. 上下文失稳 —— 信息太多，关键状态开始丢失，回复质量明显下降 4. 协作失稳 —— 多轮次或多 agent 之后的边界和结果开始冲突 5. 验收失稳 —— 看起来差不多了，但实际上无法判断能不能交 请只输出： 1. 当前属于哪一类（5 选 1） 2. 判断依据（引述具体症状，2~3 句） 3. 现在最应该停止做什么 4. 现在最应该收缩成什么子问题 5. 下一步应该用什么方式重新开始

诊断后按类型对号入座：

• 认知失稳 → 回到阶段 1，重新确认问题定义
• 路径失稳 → 用下方"急救 1：卡 bug"
• 上下文失稳 → 用下方"急救 2：上下文清理"
• 协作失稳 → 回到阶段 3，重新对齐骨架
• 验收失稳 → 回到阶段 6，用证据说话

急救 1：当 AI 陷入同一个 bug 反复试错时（路径失稳）

不要直接继续改代码。我们现在卡在一个 bug 上。 请切换成调试模式，只做下面几件事： 1. 复述当前症状（不带猜测） 2. 给出最小复现路径（具体命令和输入） 3. 列出最可能相关的文件或模块 4. 先写一个能稳定复现问题的测试用例或命令 5. 在没有新证据之前，不要继续沿刚才的思路修改。 如果当前上下文已被错误路径污染，请直接告诉我应该清上下文或回退到哪个检查点。

急救 2：当对话太长、AI 开始忘记约束时（上下文失稳）

当前上下文可能已经过载。请先做一次"状态压缩"： 1. 总结到目前为止已完成的功能（按模块） 2. 总结当前未解决的关键问题 3. 重新列出 `01_问题定义.md` 中的硬约束，确认是否仍被遵守 4. 输出一份"交接文档"，只包含下一步必须知道的信息 然后我们将清空对话，从这份交接文档重新开始。

急救 3：当任务越做越散、偏离 MVP 时

我们可能超出了最小闭环范围。请停下来，回答： 1. 当前做的这件事是不是必做功能或高优先级异常处理？ 2. 如果不做，能否正常交付并解释为"已知限制"？ 3. 请重新输出一份"剩余高优先级任务清单"，只列今天必须完成的 3 项。 之后只实现这 3 项，其他全部放回 backlog。

笔试时间分配建议（2 小时）

加分项策略：只有在阶段 6.5 评审通过（或时间不足已转为已知限制）且剩余时间 ≥ 15 分钟时，才做加分项。做法：重新执行阶段 2~5（但只针对加分功能），且尽量不修改已有必做代码。

如果笔试只有 1 小时：可考虑使用下方"备选策略：一次性全流程交付"，用一个总控提示词驱动全流程。

备选策略：一次性全流程交付（适合 1 小时笔试或紧急情况）

如果你的笔试时间只有 1 小时，或者你对题目方向非常确定，可以用下面这个"总控提示词"替代阶段 1~7 的逐步推进。它会驱动 AI 一次性完成从需求到文档的全流程。代价是中间缺少人工介入点，出错了回滚成本高。慎用，作为 B 计划。

请基于需求文档 `requirements.md` 对项目执行"一次性全流程交付"，按照以下阶段严格推进并持续输出结果： （1）需求对齐 —— 先输出《实施计划》与任务清单（必做/加分、优先级、验收标准、风险）。 （2）开发实现 —— 先确保必做功能全部可用，再实现加分功能；每完成一项给出代码变更说明与验证命令。 （3）完整测试 —— 按照"环境检查→依赖检查→单元测试→接口测试→端到端启动测试→异常与边界测试→日志排错"执行；每步给出通过/失败及原因。 （4）自动修复与回归 —— 若失败，自动修复并重测，直到项目可稳定运行。 （5）文档交付 —— 生成 `README.md`（安装、运行、配置、验证）与《项目交付总结》（已完成功能、测试结果、遗留问题、后续建议）。 最终请输出： - 可复现运行命令（Windows / Git Bash） - 测试结果汇总表 - 已完成清单（必做/加分） - 仍存在的问题与影响范围