不懂技术栈呢，验收不了

提问

不懂技术栈呢，验收不了

回答

不懂技术栈也要验收，而且完全做得到。关键在于验收的对象是「行为」还是「代码实现」，前者跟语言无关，后者才需要懂技术栈。

第一步，把验收标准写成可观察的行为。「接口返回 201 和 id」一条，「email 格式错了返回 400」一条，「重名返回 409」一条。这些你不懂 Node 还是 Java 都无所谓，结果对不对自己能判断。让 AI 在提交时附上每条标准的验证结果：用了什么命令、看到了什么输出、贴原始返回。你只看输出，跳过代码。

第二步，找一个你不懂的矛盾点就问「为什么」。看到 try/except: pass、看到一堆 if 嵌套、看到测试断言写成 assert True，不用懂技术栈也知道有问题。追问一句「这段是干什么的，为什么这么写，有没有更简单的写法」，AI 要么解释清楚，要么就是在糊弄，两边你都赢。糊弄的典型信号：解释里出现「这样比较灵活」「通常约定」，但说不出具体场景。

第三步，用对比法。让 AI 实现同一个功能两次，或者让它说明为什么不用另一种更简单的方式。你不需要判断哪一版更好，你需要看它能不能说清楚取舍。说不清的就是没想清楚。

第四步，让检查自己替你做。lint、类型检查、单测、CI 这些工具跑出来的红绿不需要你懂语法。你说的「保证质量」，靠的是门禁而不是你的眼力。把门禁设好，红的就是没过。

第五步，也是你当前最该用的：先跑通一条最小的真实操作路径。你自己点一遍、用 curl 或 Postman 发一次请求、看数据库里数据对不对。这个是黑盒，你不需要知道内部怎么实现。系统的 bug 有相当一部分在接口层和边界条件上，肉眼实测能抓出来。

最后一条心态上的：不懂技术栈时，你的角色是需求方和验收方，不是审查方。需求方只要坚持「我说清楚要什么、你证明给我看达成了」，就够了。真正需要读代码的场合是「怀疑它选错了方案」，那时候去问人或者让 AI 给你讲一遍这个方案的代价，比自己硬读划算。

你现在这个子系统是什么语言、你手上有没有接口文档？说一下我可以给你一份具体的验收清单。