阶段 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.5LLM-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 小时阶段耗时累计阶段 0 准备2 min2 min阶段 1 问题定义5 min7 min产品经理分析(可选)3 min题目偏应用类则做否则跳过10 min阶段 2 方案选择5 min15 min阶段 3 系统骨架5 min20 min阶段 4 最小闭环35 min55 min阶段 5 异常边界15 min70 min阶段 6 验收自检10 min80 min阶段 6.5 独立评审15 min含一轮迭代修复95 min阶段 7 交付文档10 min105 min剩余15 min加分项 / 手动验证 / 补漏120 min加分项策略只有在阶段 6.5 评审通过或时间不足已转为已知限制且剩余时间 ≥ 15 分钟时才做加分项。做法重新执行阶段 2~5但只针对加分功能且尽量不修改已有必做代码。如果笔试只有 1 小时可考虑使用下方备选策略一次性全流程交付用一个总控提示词驱动全流程。备选策略一次性全流程交付适合 1 小时笔试或紧急情况如果你的笔试时间只有 1 小时或者你对题目方向非常确定可以用下面这个总控提示词替代阶段 1~7 的逐步推进。它会驱动 AI 一次性完成从需求到文档的全流程。代价是中间缺少人工介入点出错了回滚成本高。慎用作为 B 计划。请基于需求文档 requirements.md 对项目执行一次性全流程交付按照以下阶段严格推进并持续输出结果 1需求对齐 —— 先输出《实施计划》与任务清单必做/加分、优先级、验收标准、风险。 2开发实现 —— 先确保必做功能全部可用再实现加分功能每完成一项给出代码变更说明与验证命令。 3完整测试 —— 按照环境检查→依赖检查→单元测试→接口测试→端到端启动测试→异常与边界测试→日志排错执行每步给出通过/失败及原因。 4自动修复与回归 —— 若失败自动修复并重测直到项目可稳定运行。 5文档交付 —— 生成 README.md安装、运行、配置、验证与《项目交付总结》已完成功能、测试结果、遗留问题、后续建议。 最终请输出 - 可复现运行命令Windows / Git Bash - 测试结果汇总表 - 已完成清单必做/加分 - 仍存在的问题与影响范围