AI Coding学习

1、核心思路

把一次性完成的编程任务，拆成"理解需求---设计---分模块实现---测试---联调---修复"的连续流程

流程总览：

阅读 README  ->  需求总结与任务优先级划分 ->  按模块分别开发与单元测试  ->  整体联调  -> 根据bug进行修复

2、具体流程

2.1 阅读readme，需求总结与任务划分

先让AI阅读README，输出：

• 题目目标和最终交付物
• 输入、输出以及约束条件
• 已有代码结构和可复用部分
• 运行方式、测试方式和验收标准
• 不明确或存在风险的地方

然后按优先级拆分需求：

• 核心任务：不完成就无法通过主流程的基础能力
• 重要任务：影响主要功能完整性的拓展能力
• 优化任务：边界增强、代码质量、性能和体验优化

先保证核心任务，在根据时间处理任务二和任务三，避免一开始陷入细节

角色：资深系统架构师。
任务：阅读项目根目录的 README.md 和现有代码结构，不要写任何代码。
输出要求：严格按以下格式输出到 problem.md：
1. 目标与交付物：用一句话说清最终产出。
2. 输入/输出/约束：明确数据格式、边界值（如最大长度）、运行环境限制。
3. 现有资产：列出 utils/ 或 common/ 中可复用的函数及接口。
4. 运行与验收：启动命令、测试命令、评分标准（如通过率要求）。
5. 风险与澄清点：凡是描述模糊的地方，必须标记 [待确认]，严禁假设。

完成后，按 MoSCoW 原则拆分需求：
- P0 核心：主流程必须打通的基础能力。
- P1 重要：错误重试、边界处理等完善功能。
- P2 优化：代码优雅性、日志、性能微调。

2.2 设计文档：实现路径

写代码前，让AI 生成并确认设计文档，至少包括：

• 总体方案和技术选型
• 模块拆分和目录结构
• 每个模块的职责和依赖关系
• 类、函数、接口/API 设计
• 数据结构、状态流转和异常处理
• 开发顺序与每一步的验收标准
• 测试策略和关键测试场景

明确要求：不同职责拆分到不同的python文件中，不要把所有逻辑写在一个文件里

角色：Python 技术专家，追求简洁高效的工程结构。
任务：基于 problem.md 设计实现方案，要求优先考虑稳定交付，而不是最复杂高端，输出到 task.md。

硬性条件：方案至少包括
1、总体方案和技术选型
2、模块拆分和目录结构
3、每个模块的职责和依赖关系
4、类、函数、接口设计
5、数据结构、状态流转和异常处理
6、开发顺序和每一步的验收标准
7、测试策略和关键测试场景

2.3 每个模块单独开新会话开发

一次只处理一个模块，并把设计文档中对应的内容提供给AI：

1. 说明当前模块的目标、输入输出和接口约束
2. 按设计实现代码，保持与其他模块的接口一致
3. 同步编写该模块的单元测试和基础测试
4. 运行格式检查、类型检测和测试，记录结果

新会话有助于减少上下文干扰

角色：高级 Python 工程师，追求一次性交付高质量代码。
任务：完成模块 [模块名] 的全部开发（代码 + 单元测试），仅输出最终产物。

请按以下内部工作流自行执行：
1. 先根据 task.md 定义该模块的 Schema 和自定义异常类。
2. 实现主路径逻辑以及必要的异常捕获。
3. 编写对应的 pytest 单元测试，覆盖正常场景和至少 2 个边界异常场景。
4. 在输出前，在脑海中模拟运行测试，确保主用例逻辑无误。

输出格式：
- 第一部分：实现代码（例如 src/processors/calculator.py）
- 第二部分：测试代码（例如 tests/test_calculator.py）
- 第三部分：简要的自检说明（标注已覆盖了哪些关键场景）

约束：严禁在输出中询问"是否继续"或"请确认"，直接给出最终完整代码。

2.4 当前模块通过测试再进入下一个模块

• 先确认当前模块的主流程和边界条件
• 测试失败时，优先定位根本原因，不要直接堆叠补丁
• 修复后重新运行相关测试，确保没有引入回归
• 更新设计文档和接口说明，保持文档与代码同步

2.5 全部完成后整体联调

新开会话进行整体检查：

• 模块之间的接口、参数和返回值是否一致
• 主流程能否从入口顺利跑通
• 配置、文件路径和环境变量是否正确
• 异常处理、日志和资源释放是否完整
• 基础测试、集成测试是否通过
• 是否存在重复代码、单文件过大或未实现的TODO

联调阶段主要验证"模块组合后能不能工作"，而不是重新设计全部代码

角色：测试架构师。
任务：检查所有模块的装配与端到端流程。
检查清单（请逐项验证并输出结果）：
1. 入口检查：main.py 能否正确调用 orchestrator 或 core.process()？
2. 依赖检查：是否存在循环 import？模块间是否通过参数传值而非全局变量？
3. 资源释放：打开的文件流是否使用了 with 上下文管理器？
4. 冒烟测试：用题目提供的示例数据跑一遍完整流程，记录输出是否一致。
5. 代码健康度：是否有未使用的 import、硬编码的绝对路径、超过 100 行的巨型函数？

2.6 提交判分

提交后看判分结果，把失败测试点、错误信息和复现条件原样给AI：

1. 让AI解释失败原因和涉及的代码路径
2. 要求给最小范围的修复方案
3. 修复后运行失败用例及相关回归测试
4. 再次提交，重复验证，直到核心测试通过

不要只根据测试每次猜测问题，要结合完整报错、输入输出和调用链分析

角色：高级故障排查专家。
任务：针对评测机返回的失败点进行根因分析与修复。
请粘贴以下信息：
- 测试用例输入：[粘贴数据]
- 期望输出：[粘贴预期]
- 实际输出与错误栈：[粘贴完整报错]

分析要求：
1. 先解释根本原因（是数据类型错了、索引越界、还是浮点数精度问题？）。
2. 给出最小改动的修复代码，并说明该改动为什么不会破坏其他 P0 功能。
3. 将该失败用例补充到对应的单元测试中，防止回归。

别人实际情况使用的提示词：

1、我们可以看到，提交后判题系统一共会检测59个用例，你目前自测的只有20多；
而且判题系统的复杂用例的18个目前只过了一个，说明现在在复杂场景的逻辑下远远不足，
你再根据 @README.md 检查一下 @sample_testcases/run_sample_testcases.py 有什么完善的用例

2、你根据这个log，首先检查一下是脚本
@sample_testcases/run_sample_testcases.py 和 @readme.md 不一致的问题，
还是确实 @main.py 里实现存在问题