AI 写完了,你会改吗?eStack 让助手反过来考你

AI 写完了，你会改吗？eStack 让助手反过来考你

AI 交了作业，还会反过来考你

← 左右滑动

01PART 01

01｜代码交付以后，还有一笔理解债

设想一个场景：你让助手给日报脚本加上失败重试，界面显示任务完成，你也成功跑通一次。第二天接口报错，脚本却连续发送了两份消息。此时你要回答的不是“代码在哪里”，而是“哪些失败可以重试，哪些动作重做会产生副作用”。

这是本文设计的教学例子，不是 eStack 的实测案例。它说明了一个常见缺口：拿到能运行的结果，与能够维护结果，是两种能力。让助手写一大段解释也未必够，因为人很容易把“读着顺”当成“已经懂”。

eStack 的学习流程试图补上这一步。先让助手围绕实际文件讲清楚，再要求使用者自己预测结果、识别问题或复述原因。对一边做项目一边学编程的人，这比记住一长串技能名称更有用。

02PART 02

02｜先分层解释，再一题一题回答

explain 的文件要求从浅到深展开：先用一句话说明用途，再解释为什么需要它、主要步骤如何连接，最后指出容易出错的地方。需要更深内容时才继续，不默认把每次提问都变成长课。

它还要求使用真实代码和名称；拿不准就读代码或运行检查，说明自己查过什么。放到重试脚本里，你可以让它只讲“请求失败后会经过哪些判断”，并指出决定是否再次发送消息的具体位置。

接着运行 quiz-me。它默认围绕本次改动或指定文件，挑出三到五个维护者必须理解的要点，一次只问一题，等你回答再继续。题型可以是预测行为、找错误、选择判断或用自己的话解释。

这里真正有价值的是纠错：答错应指出错误、给出解释并定位代码，结束时总结薄弱点和下一步阅读动作。不要先让它公布全部答案；可以先自己写出判断，再回到文件核对。测验的用途是暴露盲区，不是制造一个漂亮分数。

03PART 03

03｜十四个技能，不必一次全开

当前 README 列出十四项技能，覆盖学习、开发、内容传播，以及写作和任务路由。路由器 estack 会根据目标挑选合适技能。对于今天的学习任务，先用解释与测验就足够。

如果准备修改较复杂的功能，可以先用 premortem 想一遍“这次改动可能怎样失败”，把风险变成检查事项；涉及页面时，再用 verify-ui 进行浏览器检查。它们提供的是检查流程，能否执行仍取决于宿主有没有相应工具。

完成产品后的博客、社交内容和短视频脚本，也有对应技能。这里应把官方描述当作工作范围，而不是效果保证：有搜索优化流程，不代表文章必然获得流量；有检查清单，也不代表软件自动变得可靠。

04PART 04

04｜免费的是技能，模型与验证另算

eStack 使用 MIT 许可证，技能文件可免费获取和修改。但调用模型仍走你现有助手的订阅或接口额度，联网服务也有自己的条件，不能把开源理解为所有使用成本都归零。

两个涉及实时信息的技能尤其要分清：catch-up 可以在未连接 explainx.ai MCP 时使用网页搜索；pick-model 则可以转向模型厂商价格页，并注明读取日期。MCP 是让助手调用外部服务的连接方式，这里是可选增强，不是学习流程的前提。

官方没有给这套文本技能规定统一的最低显存或内存。实际要求来自你选用的助手、模型和浏览器工具；本文不据此承诺任何旧电脑都能流畅运行。

同样要留意，讲解和评分都由模型完成，也可能理解错代码。答对一道题不能替代真实测试，更不能替代发布前审查。适合它的是愿意动手核对的小项目维护者；如果只想交出文件、不打算参与学习，这套问答流程反而会增加时间。

05PART 05

05｜从一个能复查的小改动开始

第一步，进入文末官方仓库，核对作者 whyashthakker 和项目名 estack，先阅读安装说明及 explain、quiz-me 两份技能文件。技能是给助手读的工作指令，安装前看一遍，能知道它将读取什么、怎样提问。

第二步，按宿主选择安装方式。Claude Code 用户可在其会话中先执行下方市场添加命令，再安装插件；也可以按仓库说明，把技能文件夹放到对应目录。已有同名技能时先处理冲突，避免不清楚实际加载了哪一份。

第三步，选一个你能核对的小改动，例如脚本输入为空时给出提示。让助手完成后，明确要求 explain 只解释本次改动，再用 quiz-me 检查自己是否知道空输入会走哪条分支。

试用时可以这样提出任务：“先读这次改动，解释数据从哪里进入、在哪里校验、最后写到哪里；只讲我维护它必须知道的部分。然后逐题考我，等我回答后再给解释。”这是本文建议的提问方式，不是额外安装命令。

如果助手的问题只考函数名字，可以要求它改问行为：“删除空输入判断会怎样？失败后会留下半成品吗？怎么发现重复写入？”这些问题应该由当前代码决定，不要让模型先编造一个故障，再把它当作项目事实。遇到答案和运行结果不一致时，保留两者，追查具体分支。

第四步，自己构造正常输入和空输入，观察结果，再把答错的问题带回代码。建议把这次改动、检查方法和仍不理解的地方记下来，下次维护时再用，而不是每次从头听解释。

衡量这次试用是否值得，可以看一个具体结果：关掉助手以后，你能否说清这段代码为什么存在、哪里可能失败、怎样确认改动有效。如果仍说不清，就缩小问题继续问。代码写完只是交付，理解到能修改，才开始成为自己的工具。