研讨题
公开教程 · 无需登录

研讨题

下面二十九道题按「建仓库 → 定规约 → 立规范 → 五类规范 → 落骨架 → 协作节奏」分组，全部围绕一件事：同样的目标，怎么做才算工程上可维护。每题都没有唯一答案，但都有可对照的判据——讨论的价值不在于统一意见，而在于把分歧点说清楚，再把结论落到具体文件中。

1怎么用这些题

讨论容易停在「两种做法都说得通」。下面三条规则用来把结论收敛到能落地的那一个。

  1. 先选择，再讲理由。每人对每题先给出自己的做法，再解释为什么；顺序颠倒则退化为复述教材。
  2. 指明自己仓库中的具体路径。说「我们会在 src/ 下分层」比说「分层很重要」更有说服力；无法指出具体路径，说明尚未落实到实现。
  3. 每题收束到一个落点。结论要么改规约（设计与需求条目），要么改规范（规则文件或技能），要么改代码骨架；三者都不是的，不构成结论。
每题先讨论、后对照：参考思路在下一页，讨论完再看——先看则失去分歧。

2仓库与协作（四题）

本组关注：哪些约定一旦省略，事后补做的代价会成倍上升。

  1. 忽略规则未先于代码入库——如何补救？密钥被提交进了历史，删除文件与重写提交历史都无法抹去它已进入版本历史的事实。讨论：此时正确的补救是轮换该密钥，还是重写提交历史？把这一步写进 README 的哪一处？
  2. 四个人共用一个主干，还是每人一条长期分支？主干随时可启动的代价是每次改动都要小步合并；长期分支的代价是合并时一次性对齐。讨论：四人规模下哪种总成本更低，判据是什么？
  3. 变更名用日期还是用能力名？半年后要找「那次改分层的改动」，两种命名各自的检索路径是什么。讨论：能否两者都用（日期前缀 + 能力短名），代价是什么？
  4. 配置样例是否填写示例值？填写示例值可降低上手成本，但会诱导成员直接改为明文值提交。讨论：仅写键名的代价是什么，如何在 README 中补充取值途径？

3规约与边界（四题）

本组关注：什么样的描述才可被判定。

  1. 「用户能提交作业」算不算一条可判定的需求？讨论：应改写为何种形式，才能在验收时当场判定其是否满足；仅替换一个词是否足够。
  2. 可观测结果写成「系统处理成功」为什么不行？讨论：举例将其改写为当场可见的现象；若该现象只能从日志中观测，是否仍算可观测。
  3. 失败路径需覆盖几条？超时、并发重复提交、权限不足、参数缺项——讨论：哪些必须写进规约，哪些属于实现时自行处理的细节，判据是什么。
  4. 验收说「另起一次不带上下文的会话，只给出仓库路径与变更名即可照做」——为什么这条能验出规约真的够用？讨论：无法做到时，通常缺失哪一类信息（背景、判定条件，还是任务切分）。

4规范与 Harness（五题）

本组关注：约束写在哪、粒度多细，以及如何确认其生效。

  1. 「所有接口必须校验入参」与「给新模块补一套测试」——分别落在规则还是技能？讨论：判据是不是「每次改代码都要读到」还是「按场景才会用到」，举自己项目里的两条约束验证这个判据。
  2. 规范写太细会怎样？细到规定函数行数与后缀拼写，后果是什么；粗到「代码要清晰」则如何。讨论：以什么判据把握粒度（例如「不写就会被不同的人写成两样」）。
  3. 规则文件放在仓库里，还是放在各人本机的配置里？讨论：怎么保证四个人读到同一份；规范升级时，如何保证全员同步切换而非各自保留旧版本。
  4. 如何验证规范确实生效？除「修改一次代码检查生成产物」外，还能设计什么更强的检查（例如故意实现一个违反规范的用例，检验是否被拦截）。
  5. 规范与规约冲突时先改哪个？规范要求分三层，本次变更的设计采用两层。讨论：两种改法各留下什么痕迹，改动如何记入变更说明。

5骨架与分层（四题）

本组关注：骨架的边界划在哪里。

  1. 骨架是否应包含认证与授权？提前实现的好处是后续每课无需重复实现；讨论：判据是「后续课次都要用」还是「这次就要用」，两者冲突时以哪个为准。
  2. 健康检查为什么要免认证？讨论：该端点返回哪些字段是恰当的（状态码、版本号），返回哪些属于信息泄露（依赖地址、配置项名称），判据是什么。
  3. 哪些内容看似配置、实则应由版本控制管理？提示词模板、评分细则、错误码表。讨论：区分「随环境变」与「随版本变」的判据，以及放错位置会在哪一步暴露问题。
  4. 骨架为什么要打标签？讨论：若未打标签，后续哪一步会变得困难（回滚、对比、说明某次改动的来源）。

6协作节奏与取舍（四题）

本组关注：多人协作叠加 Harness 之后，迭代节奏如何确定。

  1. 三名成员需修改同一文件：事后冲突合并，还是事前任务切分？讨论：在 Harness 参与生成的前提下，事后冲突合并与事前任务切分何者成本更高，判据是什么。
  2. 一次性生成整套业务，还是每次仅执行一组任务？讨论：无法启动时，两种做法的故障定位成本差异何在；「每次一组」是否在任何情形下都更优。
  3. 代码评审看什么？代码风格、规范覆盖度，还是规约覆盖度。讨论：人工评审与 Harness 审查如何分工，哪些事项只能由人判定。
  4. 实现过程中发现规约存在错误：先按原规约实现，还是先修订规约？讨论：两种顺序各留下什么痕迹；修订规约时如何保证改动可追溯（变更说明中应记录哪些内容）。
本组题没有标准答案，但有共同判据：改动之后，下一名接手者能否仅凭仓库中的内容继续实现——能，即为工程上可维护的做法。

7规范取舍（八题）

本组关注：每条规范背后的取舍，以及为什么判据比篇幅重要。前五题对应五类必修规范，后三题对应三类补充规范；可按「规范案例：CampusClaw」中的样例文件逐题对照。

  1. 术语表该写进产品设计规范，还是写进规约？界面用词变更不影响对外契约，而同一概念的字段命名会影响；讨论：两者的边界在哪，谁先发现不一致。
  2. 错误码集中登记，还是各模块自管？集中可统一遍历与查重，分散则容易产生重复编号；讨论：判据是「调用方是否需要按模块分支处理」，还是「登记的步数」。
  3. 为什么「跨班一律 404」而不是 403？403 会区分「不存在」与「无权访问」，泄露资源是否存在；讨论：在本项目这种按班隔离的场景里，泄露的是哪一类信息。
  4. 覆盖率门槛按代码行数，还是按失败路径数？行数可在无关的 getter 上凑数；讨论：改成「能力的失败路径是否被覆盖」之后，哪一类用例数量会最先变化。
  5. 回滚能力该什么时候演练？发布之前演练，还是在故障发生时再验证；讨论：未演练过的回滚在故障场景下是否可用，演练记录应落在哪一份文件里。
  6. 提示词该放进配置，还是随版本入库？讨论：判据是「随环境变」还是「随版本变」，两者的后果分别是什么。
  7. 删除一条数据要删几处？业务库、向量库切片、对象存储、缓存、备份；讨论：谁维护这份副本清单，删漏了在哪一步才会被发现。
  8. 完成定义写在哪，由谁判定？讨论：写在根目录说明文件与写在会话里的差别；口头共识在换一次会话之后还剩什么。
← 骨架与核查清单 参考思路 →