笔试记录

prompt我做的也不怎么样，这里只复盘AI Coding，拿了70左右，说下我的方法论(让AI帮我润色了下--- 核心思路：不要让 AI 一上来重写项目，也不要反复让它“帮我 review”。AI Coding 笔试真正有效的做法，是让 AI 围绕一条条可执行失败用例做最小修改。 1. 开局不要急着改代码 第一轮对话目标只有一个：建立 baseline，找到第一条失败时间线。 可以直接这样问： 你现在是我的 AI Coding 笔试助手。 不要重写项目，先帮我读题和读现有代码，目标是建立 baseline。 请按顺序完成： 1. 总结题目要求，只提炼状态、时间、金额、幂等这几类不变量； 2. 找到项目入口、核心数据结构、核心状态流转位置； 3. 告诉我如何编译和运行公开样例； 4. 设计第一条最小失败时间线； 5. 暂时不要修改代码，先输出理解和验证计划。 这一步不要追求计划完美，先跑出第一条失败场景。 2. 先跑 baseline 开局确认四件事： 原始代码能不能编译； 公开样例通过多少； 核心状态存在哪里； 第一个最小失败场景是什么。 不要一上来让 AI 推倒重写。工程题牵涉多个状态，重写很容易把原本能跑的接口弄坏。 3. 每轮只修一个机制 不要让 AI 同时修试用、暂停、欠费、余额、改套餐。每轮只盯一个机制。 比如： 试用到期有没有生成首张账单； 暂停跨周期后账单时间有没有顺延； 欠费重试会不会重复扣费； 多订阅之间会不会串数据； 同一个事件重复触发是否幂等。 问题越小，AI 越容易修对。 4. 不要让 AI 只 review，要它写失败时间线 最有用的提示词： 不要继续给风险清单。只选一个最可能影响当前分数的问题， 写成最小 API 时间线，并说明： 1. 修改前为什么必然失败； 2. 每一步要观察什么状态、账单数量和金额； 3. 最小修改范围； 4. 修改后要回归哪些旧场景。 比如试用到期场景： reset 创建 trial_days=7 的套餐和客户 创建订阅，确认状态 trialing，且没有 Invoice advance 到 trial_end 前 1 秒，确认没有账单 advance 到 trial_end，确认状态 active，且恰好生成一张 first_charge 再次 advance 到同一时刻，确认账单不重复生成 这比“帮我看看哪里有 bug”有效很多。 5. 测试全绿时，也要怀疑测试太弱 如果 AI 写了一批测试，但生产代码没改，测试也全过，说明测试可能没打到真实错误。 每个新测试都要检查： 它能不能打红当前错误实现； 是否检查了状态变化； 是否检查了账单数量； 是否检查了金额； 是否检查了重复执行不会重复生成结果； 失败信息是否明确。 绿色结果不一定可信。能把错误实现打红的测试，才有价值。 6. 分数不变，就换根因假设 如果连续几次提交都是同一个分数，不要继续让 AI “再 review 一遍”。这说明当前方向没有区分度。 这时候要换问题问： 是不是时间边界错了； 是不是状态迁移没触发； 是不是账单重复生成； 是不是多订阅串数据； 是不是两个机制组合时互相污染。 分数不动，很多时候是你问的问题没有打到隐藏用例。 7. 涨分后立刻保存 checkpoint 从低分涨到 70+ 后，不要继续大范围改。剩下的分数通常是组合边界，乱修容易掉分。 后续节奏： 冻结当前版本； 每次只加一条复合时间线； 修改前确认测试会红； 修改后跑局部测试； 再回归已经通过的旧场景； 最后再正式提交。 8. 最终可复用节奏 可以直接照这个流程做： 1. 读题和代码，不改代码； 2. 跑 baseline 和公开样例； 3. 提炼状态、时间、金额、幂等四类不变量； 4. 选择一个最危险机制； 5. 让 AI 写最小失败 API 时间线； 6. 确认测试能打红当前实现； 7. 让 AI 给最小 patch； 8. 跑新增测试和旧样例； 9. 提交，保存分数和反馈； 10. 分数不变就换根因假设，分数上涨就保存 checkpoint。 AI Coding 笔试不是让 AI 一次性写满分代码，而是让 AI 根据失败用例快速修局部问题。人负责选场景、跑验证、质疑绿色结果、控制改动范围；AI 负责解释失败、写最小 patch、补回归测试。