参加那次短期挑战营以前，我做小项目的方式很直接。想到一个功能，选一套熟悉的技术，先把第一版搭出来。给自己写工具时，这个办法常常有效，我同时知道问题在哪里，也知道什么样的结果够用。
久而久之，听见一个新问题，我脑子里最先出现的总是页面、数据和 Agent。它们来得很快，很快就能排成一套像样的方案。方案越完整，我越容易误以为自己已经理解了问题。
活动开始时，老师让我们先别急着找“一个 AI 创意”。先去看一件具体的工作：谁会在什么时候遇到麻烦，当前怎样处理，为什么原来的办法会卡住。
这个要求听起来很普通。试着照做时，我才发现从问题出发比建一个项目骨架难得多。骨架会顺着我的设想长下去，现实却经常对设想没有反应。
介绍听完了，问题还没有出现
最初几天，我们跟着安排了解不同场景。介绍、参观和问答接得很紧，我的笔记里很快积下许多名词：设备、系统、数据、流程，还有未来可能加入的智能能力。
这些信息帮助我认识背景，也很容易被整理成一份内容完整的汇报。可当我回去看笔记，仍然答不上来一个简单的问题：如果明天什么新系统都不加，哪件麻烦还会照常发生？
介绍通常从已经形成的流程说起。它会告诉我们一件事应该怎样运行，各部分如何配合，做到了哪些改进。学生去调研时，很容易顺着这条线继续问，最后得到更多完整的介绍。页面和架构也会在这个过程中自然长出来，因为每一个名词都像能接上一项功能。
我起初也这样做。刚听到经验难传递，就想到知识库；听到数据分散，就想到统一入口；听到判断依赖个人，就想到让模型给出建议。每个方向都说得通，放在一起也很完整。只是它们离每天发生的那件小事还很远。
后来我把问题换了一种问法：不再追着“还能增加什么能力”，先留意流程中已经存在的停顿。哪些地方需要反复确认，哪些信息总要临时补充，哪一步遇到例外时会回头找旧记录。方向缩小以后，笔记反而没有那么漂亮了，里面多了许多问号。
看介绍之外留下的痕迹
那几天的笔记里，有一处很明显的方法变化。起初我主要记录讲解中的概念，后来开始留意日常流程留下的记录和行为。原始笔记涉及具体现场，这里不展开其中的人和事。对我有用的是观察顺序发生了变化。
现场不会主动把问题整理成一道题。流程写得很清楚，实际运行时仍会留下补充、确认和回看的痕迹。与其立刻把这些痕迹翻译成功能，我更应该先问它为何出现，在什么情况下被需要，同样的情况是否反复发生。
一条记录的分量也有限。它可以提示下一步往哪里看，还不足以支撑一套完整需求。调研中遇到恰好支持设想的线索，最容易让人兴奋；这时把范围写窄一点，反而能保住它原来的意义。
于是最初那个很大的设想逐渐缩小。我开始考虑的只是某个明确环节：当相似情况再次出现时，能否更快找到过去的记录，把需要注意的项目摆在眼前，再由使用者决定这次是否适用。
这里仍然有很多没回答的问题。多一次查看会不会增加负担，旧记录是否足够清楚，模型给出的相似结果会不会把人带偏，使用者是否愿意补充新的判断。它还称不上方案，只是一组可以继续询问的问题。
页面只写下了一种设想
活动期间，我搭过一版用于整理材料、记录依据和汇总进展的系统。保留下来的开发记录能对上这版页面的存在，它当时怎样被使用、是否适合活动节奏，没有同样完整的材料。
所以我愿意把它写成一种设计意图：希望分散的信息能放在一起，希望提出判断时顺手留下依据，希望后来的人可以回看方向怎样变化。至于这些愿望有没有发生，正文停在问号这里。
以前写项目复盘，我常常把“做出来”与“产生效果”挨得很近。两句话之间其实隔着使用。有人是否愿意多填一项，记录方式会不会带来额外负担，整理后的内容有没有在下一次判断中派上用场，都要在页面之外观察。
Demo 仍然有用。至少它把设想变成了可以检查的字段和步骤。只是检查的结果不应由开发者提前代写。保留下来的那版页面只能算一次尝试，还不能算已经落地的方法。
工具也会继承问题的偏差
这次调研还让我反复想到一件事：整理得有条理，不会自动让材料变得可靠。如果收集时只留下支持原方案的线索，系统会把偏向也整理得井井有条；如果一开始就把角色想错了，增加更多字段只会让填写变得更累。
因此，页面之前的那些问号不能被省掉。问题多久出现一次，现有办法为何没有解决，增加一步操作会带来什么负担，谁来判断系统给出的内容是否适用。答案并不都要在开工前齐全，至少要知道哪些仍是猜测。
我以前喜欢功能清单带来的踏实感。一行一项，勾完以后像是事情正按计划推进。调研留下的问号没有这种整齐，却更接近当时掌握的程度。它们提醒我，尚未了解的部分依然在场。
让方案晚一点出现
活动结束后，我还是会在听到需求时想到页面和架构，也还是喜欢把模糊念头迅速做成能点的 Demo。这部分习惯没有突然改变。
现在只是多做了一步：在开工前，先把还没弄清的地方写出来。
再听见一个问题，我想先弄清它由谁处理，发生时手边有什么，已有办法为何不够用。一个很合适的回答出现后，还要看看它来自一次偶然，还是反复发生的情况。技术进入以后会增加哪一步，这一步以后由谁照看，也应留在问题里。
这些问题可能让原来的方案缩小，也可能让它换个方向。对习惯迅速开工的人来说，这种停顿并不舒服。编辑器已经可以打开，仓库名字都想好了，再退回来承认问题还没看清，需要一点耐心。
我仍然会做方案，只想让它晚一点出现。介绍提供背景，日常留下的痕迹把问题拉近，有限的样本则提醒我别急着说满。等问题慢慢有了轮廓，页面从哪里开始，也会比最初那张热闹的功能清单清楚一些。