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