“先把电脑合上吧。”
挑战营开营第一天上午，带队老师站在讲台前说了这么一句。我面前摊着刚建好的空白文档，手指还悬在触控板上，脑子里已经在盘算这次用哪套前端模板、接哪家的模型接口了。听到这句话，我愣了一下，有点不情愿地把屏幕按了下去。
来这个夏季短期挑战营之前，我折腾个人小项目的路数一向直接：冒出一个点子，挑一套熟悉的技术栈，三下五除二先把第一版页面跑起来再说。关起门给自己写小工具时，这法子几乎百试百灵——我自己就是唯一的用户，痛点卡在哪、做成什么样算顺手，心里早有一本明账。
可这种爽快的正反馈持续久了，人会不知不觉染上一种“代码条件反射”。别人刚提起一个问题，我脑子里第一时间跳出来的就是页面布局、表结构和 Agent 的调用链路，对方话音还没落，一张环环相扣的架构图已经在心里排好了。方案越眉目清晰，我就越容易飘飘然，以为自己已经把问题看透了。
老师那天的意思很朴素：别急着找一个惊艳的 AI 创意，先老老实实下到现场去看——是谁在什么时候会撞上麻烦，他们眼下靠什么土办法应付，原来的流程又为什么偏偏在那里卡住。
真跟着队伍走进作业现场，我才发觉，顺着真实的问题往深处摸，比在编辑器里初始化一个项目骨架难多了。代码骨架总是温顺地顺着开发者的设想往上长，真实的日常运转，却常常对我们精心搭好的设想毫无反应。
介绍听得越全，问题藏得越深
头两天，我们顶着大太阳密集地走访了好几个业务现场。展厅讲解、车间参观、集中座谈一环扣一环，我的活页本很快就攒下一大串专业名词：从硬件设备、业务系统、数据流向到标准作业流程，页脚还缀着不少“未来计划引入”的智能化设想。
傍晚回到驻地，把这些笔记敲进电脑，很容易就能拼出一份结构工整、内容详实的调研汇报。可夜里十一点，我对着满屏的流程图发呆，发现自己连一个最简单的问题都答不上来：假如明天这里一行新代码都不写、一套新系统都不上，哪一件具体的麻烦，第二天早上八点半还会照常发生？
现场的正式介绍，习惯从一套已经成型、运转良好的标准流程讲起：事情应当怎么推进，部门之间怎么配合，这几年做成了哪些改进。我们作为学生去调研，很容易顺着讲解人的逻辑往下追问，最后收获更多滴水不漏的宏大介绍。听着听着，脑子里的页面和架构也开始疯长，因为讲解词里的每一个抽象名词，听起来都像一个现成的功能入口。
我头两天就彻底掉进了这个惯性。刚听到一句“老师傅的经验很难传给新人”，笔就在纸边画起了知识库和向量检索的框图；刚听说“各环节的数据散在不同系统里”，马上想做一个大一统的数据中台面板；听到“复杂情况下的判断很依赖个人直觉”，就迫不及待想塞个大模型进去自动出建议。（现在回头翻那两页草稿，满纸箭头和气泡，活脱脱像一份为了凑齐技术热词硬编出来的招标书。）每条思路单拎出来都头头是道，唯独离一线的人每天真正皱眉的那件小事，隔着十万八千里。
晚上在夜宵摊跟队友复盘，发现大家撞上了一样的苦恼。第二天我们索性把提问的方向彻底拧了过来：不再仰着头追问“你们还缺什么新功能”，专挑流程里那些不起眼的停顿与卡壳去留心——哪个环节需要经手人反复掏出手机打电话确认，哪一类表格总拖到快下班才突击补填，哪一步一遇到例外就得停下手里的活，去翻几个月前的旧台账。
视线一收窄到这些具体的褶皱上，笔记本上的字迹立刻没那么整齐了，取而代之的是一串接一串悬而未决的问号。
去找流程之外的擦痕
回头翻那几天的记录，能清楚看到记笔记的习惯半途拐了个大弯。头两页记满了对方的概念解释，后面的篇幅渐渐落在日常作业留下的细微动作上：操作台角落里一张发黄的便签，值班人员随手存在微信收藏里的几条核对口诀。
真实的现场从来不会主动把痛点提炼成一道条件完备的应用题。纸面上的规章和流程图写得清清楚楚，可一落到日复一日的运转里，总会在边角留下临时手写补充、口头二次确认、翻箱倒柜查旧账的擦痕。一看见这些擦痕就兴冲冲地把它翻译成软件里的按钮，太急了。得先耐着性子问：这个多出来的动作当初为什么会出现？它在什么样的情境下才会派上用场？同样的窘境到底是偶一为之的意外，还是每周都在重演的常态？
有好几次，我们在交谈中偶然抓到了一两条能印证最初设想的线索，几个人当场对视一眼，眼睛都亮了，恨不得立刻回房间画原型。可冷静下来顺着细节多问两句，才发现那不过是某个特殊月份才撞上一次的极端情况。越是这种容易让人兴奋的时刻，越得主动把结论往回收一收，才不会让那点宝贵的现场线索在自己的过度热情里失了真。
这么一路删减下来，我脑子里那个包罗万象的大系统渐渐退去了水分，最后只剩下一个很具体的切口：一线的人再次遇上似曾相识的棘手状况时，能不能帮他更快调出过往相似的处置记录，把当年踩过的坑和要留神的核对项摆在手边——至于这次照不照搬旧例，依然由他自己拍板。
哪怕缩到这么小，里面依然横着一串没法靠拍脑袋回答的追问：在本来就紧绷的流程里多看一次屏幕，会不会反而给经手人添乱？旧记录本身写得够不够清楚？算法匹配出来的“相似案例”会不会把人往沟里带？忙完手头活儿的人，还有没有余力替系统补入新的判断依据？走到这一步，它依然算不上技术方案，顶多是一组终于找准了方向的待核实问题。
做出来的页面，只是把猜测摆上了台面
说来好笑，嘴上天天念叨别急着写代码，挑战营进行到一半的某个深夜，我还是没忍住手痒，熬到凌晨两点搭了个内部协作小工具，用来归拢调研卡片、关联现场录音、汇总小组的判断依据。第二天一早顶着黑眼圈把链接发进小组群，满心以为大家从此能告别满天飞的聊天记录，井井有条地在面板上沉淀思路了。
现实给我上了极其生动的一课。那几天大家白天在外面跑得脚底发酸，晚上回来还要争分夺秒地推翻重排路演逻辑，讨论激烈起来的时候，谁还顾得上点开浏览器、按我设定的下拉框一格格填字段？在白板上画两笔、拍张照甩进群里，或者直接在共享文档里敲几行加粗红字，比我那套精致的表单快出了不知多少倍。营期结束，我打开后台看了一眼：除了头天上午大家给面子录的几条测试卡片，整个页面冷冷清清，微信群倒是刷了几百屏。
看着那个被冷落的页面，我倒一点都不觉得沮丧，反而彻底想通了一件事。
写项目总结时，开发者太容易把“功能写出来了”和“问题解决了”这两句话紧挨着放在一起，好像代码上线那一刻，现实里的阻力就烟消云散了。可这两句话之间隔着一道漫长而微妙的鸿沟，叫“真实的使用”。协作的人愿不愿意为了日后的可追溯而在当下多填两个输入框，结构化的记录方式会不会打断正在兴头上的讨论，费劲整理的卡片到了下次做决定时究竟有没有人点开看——全都是在代码仓库之外才见分晓的事情。
那个小工具也不是全无用处。它至少逼着我把脑子里虚浮的念头，落实成了屏幕上看得见的字段和操作步骤，也让我亲眼看见，自己凭空想出来的“优雅流程”，在面对真实的高压节奏时有多不堪一击。
整理得再工整，也会继承提问时的偏见
那几天实地摸爬滚打下来，我还反复咂摸出另一层味道：把收集来的材料用表格或系统整理得井井有条，并不会让这些材料自动变得可靠。要是走进现场提问的那一刻，心里就已经揣好了非做不可的原定方案，专挑顺耳的线索往篮子里捡，界面做得再清爽，最终也只是把开发者最初的偏见整整齐齐排了一遍版；要是一开始就错估了使用者的真实处境，页面上每多一个必填字段，都是在给现场的人徒增一份疲惫。
正因如此，在画原型图、建数据库表之前的那一排问号，怎么都省不得。这个问题多久冒头一次？现有的土办法为什么偏偏在这里失了灵？引入新工具多出来的那一步，究竟由谁来买单？当系统给出的建议与现场直觉相左时，谁有足够的把握拍板定夺？答案未必非要在写第一行代码前全部凑齐，但动手的人心里至少得有一本清醒的账：哪些是已经踩实了的地面，哪些还只是悬在半空的猜测。
功能清单总能给人一种廉价的踏实感，一行一个复选框，划掉一项，就觉得项目正顺风顺水地奔向终点。调研归来留在纸上的那一堆问号，既不整齐也不提气，却像一排沉默的界碑，比清单更接近我们对真实世界到底掌握了多少。
让方案晚一点出场
从挑战营回来，我的老毛病并没有在一夜之间消失。听见一个新需求，脑子里还是会条件反射地浮出界面和接口设计，也还是保留着把模糊想法飞快敲成可交互原型的爱好。
真正发生改变的，是在双击打开编辑器之前，我会先扯过一张草稿纸，把那些还没摸透的空白老老实实列出来：这件事平时落在谁肩上，麻烦找上门的那一刻他手边仅有什么趁手的工具，沿用了多年的老办法卡在哪个具体动作上。哪怕聊到一个特别契合技术设想的漂亮回答，也想再多问一句，看它是偶然撞上的极端个例，还是日复一日都在重演的普遍困境。方案落地以后势必多出来的那一步维护，往后由谁照看，也得在动手之前先写进这张纸里。
一连串追问走下来，最初那个颇有野心的技术方案往往要缩水，甚至彻底调转船头。对一个习惯撸起袖子就写代码的人来说，这种悬在半空的停顿感并不好受——开发环境配好了，新仓库叫什么名字都想好了，却得硬生生退回来承认，自己连问题本身都还没看清。按住手指头的那股焦躁，确实要花点力气。
我依然喜欢写代码、搭系统，只是越来越愿意让技术方案晚一点出场。等那个真正让人头疼的问题在追问中一点点显出真实的轮廓，页面究竟该从哪里落笔，自然会比最初那张热闹却空洞的功能清单要清晰得多。
那张写满问号的草稿纸，现在还压在我键盘底下。