赛前随笔重庆市青创赛决赛一个方法论选手的碎碎念本文的方法论均可在 边界之内技术人的决策框架 查阅欢迎订阅四月十九日。离出发还有四天。桌上摊着论文、展板草稿、笔记本电脑还有一杯凉透的茶。窗外有鸟叫阳光很好但我不想开窗。一开窗楼下广场舞的声音就会涌进来打断脑子里那根绷了太久的弦。其实没什么好紧张的。稿子背熟了项目跑稳了展板素材也打印好了。可心里就是空落落的像考试前突然发现自己漏背了一整章——虽然那一章可能根本不考。我到底是怎么进来的第一章起点——一个不会焊电路的人1.1 “你那些东西整理一下写篇论文投投看”去年冬天的事。老师找到我说的就是这句话。语气很平常像在说“今天天气不错”或者“作业记得交”。我当时的第一反应是我论文我那些东西算科技创新吗我做的不是智能垃圾桶不是自动浇花器不是人脸识别门锁。没有电路板没有电机没有能摸能看的实物。我只有一堆文章和几个代码仓库。那些文章写的是技术判断力、工程思维、项目结构那些代码跑的是AI对话、键盘热力图、物理小球。这些东西放在科技创新大赛里像什么呢像一个写诗的人走进了工业展览馆。周围是轰鸣的机器、闪烁的指示灯、金属碰撞的声音。而他手里只有一本薄薄的诗集。老师说试试。我说行。然后就把这事忘了。1.2 通知来的那个下午开学之后日子照旧。该上课上课该写代码写代码。直到某天下午手机响了。不是电话是通知。我点开眯着眼看了几秒然后愣住。“入围终评。”就四个字。我盯着屏幕看了很久。第一反应是是不是搞错了第二反应是评委是怎么从一堆实物里把这个方法论捞出来的那天下午我没写代码。我坐在书桌前把论文从头到尾翻了一遍。不是检查错误是想确认一件事这些东西真的有人看懂了吗1.3 “有人看懂了”后来我想明白了。也许不是“捞出来的”是“有人看懂了”。我写的那些东西表面上是技术文章骨子里是一个一个坑。写《技术判断力的形成》是因为我自己选型选到崩溃。三个人三个方向每篇文章都有道理三天后更迷茫。那些文章写得都很好好到你不知道该信谁。信息是过剩的判断力是稀缺的。写《看不见的工作》是因为我自己被性能问题折磨过。用户说卡CPU在忙可代码里找不到任何“该干活”的地方。后来才发现浏览器在偷偷渲染我看不到的东西在计算我不需要的动画在传输我不需要的数据。那些“看不见的工作”才是性能问题的根源。写《项目结构的艺术》是因为我自己被烂代码坑过。三个月前的代码看不懂变量名a、b、c改一个bug引出三个新bug。git blame上写着自己的名字。那一刻我才明白代码不是写给机器看的是写给未来的自己看的。每一篇都是先有坑后有文。不是先有理论再去找案例。所以它们读起来不像论文像日记。我一直以为这些东西只有我自己能看懂。直到那个下午。那一刻我才知道有人看懂了。不是看懂了我的技术是看懂了我为什么要写这些东西。那种感觉很难形容。不是“知音”那么隆重是“你写的字有人读完了”。第二章悖论——创新教育的裂缝2.1 30分钟能看出创新素养吗这次比赛有个环节叫“创新素养考察”占总成绩30%。大概就是看你的思维能力、表达能力、临场反应。听起来很合理但我越想越觉得不对。我写了四十几篇文章全在讲“怎么在复杂中做决策”。可决策这东西不就是在真实项目里摔出来的吗你看一个人做决策不能只看他坐在那里侃侃而谈。你要看他踩过什么坑怎么爬出来的你要看他被故障折磨过多少次才学会了打日志、做监控你要看他被人质疑过多少次“这有什么用”才学会了一个人闷头把东西做出来。这些东西不是30分钟能考察出来的。比赛让我写论文、做展板、准备答辩然后评委用30分钟判断我的“创新素养”。可真正的创新素养哪是30分钟能看出来的我做五个项目每个都踩过坑、改过bug、推倒重来过。那些“看不见的工作”才是让我进决赛的东西。比赛考的是结果但真正重要的是过程。这就是悖论。2.2 展板上不能写的名字布展指南第8条内容中不得出现指导教师姓名、专家评价、媒体报道材料、以往获奖情况……所以我不能把他们的名字写在KT板上。他们帮我改了不知道多少版论文从选题到定稿一字一句地磨。没有他们这篇论文可能还停在第一版。有一次我凌晨两点发邮件问一个格式问题第二天早上七点就收到了回复。我不知道他们是起得早还是睡得晚但我知道他们比我还认真。但规则就是规则。我能理解。名字不在板上在心里。2.3 方法论不是“能摸能看”的东西我总觉得创新教育这件事有时候挺矛盾的。我们鼓励学生独立思考、大胆创新可到了比赛的时候评判标准还是偏向“能摸能看”的东西。智能垃圾桶有盖子能打开关上评委能看到。自动浇花器有水能滴出来评委能摸到。人脸识别门锁有屏幕能亮评委能看见。方法论呢它没有外壳、没有电机、没有电路板。它只有文字、代码和逻辑。这些东西看不见摸不着但它们是真的。我用了几年时间从“借来的判断”走到“自己的判断”。这个过程比任何实物都真实。但它不是“能摸能看”的。它只能被理解不能被展示。这就是方法论选手的困境。第三章方法论——三个思维模型3.1 以边界为锚所有方法的本质是划边界。默认状态下系统没有边界。浏览器渲染所有DOM元素不管你看不看框架重新渲染所有组件不管变没变事件每次触发都执行不管需不需要通信全量传输不管改了多少资源一直存活不管还在不在用。没有边界系统就会做很多“没人需要它做”的事。划边界就是告诉系统“到这里就够了别再往前。”我把这个逻辑应用到了五个层次渲染层以视口为锚。只渲染看得见的视口外的延迟加载或直接卸载。交互层以感知为锚。只响应用户感知得到的变化高频事件用防抖节流控制。通信层以变化为锚。只传输真正变化的部分用增量更新代替全量推送。数据层以复用为锚。只转换一次重复使用用BFF层做整形。生命周期层以生命周期为锚。只运行与当前状态相关的代码及时释放资源。边界划清楚了看不见的工作自然就停了。3.2 从结果倒推多数决策从“我会什么”或“什么火”出发。本质是从技术出发不是从结果出发。从结果倒推的逻辑是结果是什么 → 技术要什么 → 什么能满足。第一步定义结果。用户要解决什么问题交付时间多长谁维护以后还要加什么第二步翻译诉求。把业务语言变成技术语言。“用户要实时看到别人输入”翻译成“需要双向通信机制”。“三天内上线”翻译成“需要低学习成本的技术栈”。第三步匹配方案。根据技术诉求筛选候选方案再结合资产盘点做出选择。这个逻辑不只适用于技术选型。写代码也可以先想“这段代码三个月后的人能不能看懂”再决定要不要加注释。做架构也可以先想“这个系统要活多久”再决定要不要用复杂架构。3.3 在取舍间平衡资源永远有限时间、人力、认知负荷、预算。你永远不可能同时做到最快交付、最佳性能、最完美代码和最前沿技术。所以必须取舍。七对核心矛盾用库 vs 自研短期效率 vs 长期可控极致体验 vs 开发效率用户感受 vs 开发者感受统一规范 vs 团队自由秩序 vs 活力追新 vs 守成未来可能 vs 当下稳定通用抽象 vs 简单粗暴复用 vs 简单完美主义 vs 业务交付理想 vs 现实AI智能度 vs 稳定性创意 vs 可靠平衡不是五五开。项目初期偏向效率中期偏向规范后期偏向稳定。核心功能偏向完美边缘功能偏向交付。娱乐场景偏向智能度咨询场景偏向稳定性。平衡是知道什么时候该往哪边倾斜。3.4 三个模型的关系三个模型解决不同的问题以边界为锚做什么——划定有效作用域从结果倒推怎么做——明确起点与路径在取舍间平衡做多好——在约束条件下寻优应用顺序边界在哪结果是什么往哪边倾斜第四章五个项目——从坑里长出来的验证4.1 为什么是五个五个项目不是计划好的。是做着做着发现刚好覆盖了三个模型的验证。每个项目都是一个“坑”每个坑都让我对某个模型理解更深一层。4.2 青简问对反面案例这是第一代产品。核心问题耦合太深。创建一个新智能体要改多个核心文件——HTML、JS、提示词配置、路由。漏一个就崩。移除一个智能体也一样。聊天记录用localStorage单一键名存储换设备就丢。问题的本质是智能体的数据与代码没有分离。这正是《项目结构的艺术》里讲的“霰弹式修改”——加一个新功能要改很多处说明本应聚合的逻辑被散落在各处。这个项目没验证什么它暴露了问题。然后我写了MultiMind。4.3 MultiMind以边界为锚第二代产品。核心理念文件夹即智能体。agents/ 目录下每个智能体一个文件夹。文件夹里有头像图片、人格设定文件、聊天记录JSON。新增智能体 新建文件夹。移除智能体 删除文件夹。系统启动时扫描目录动态加载所有智能体。核心逻辑只有十几行代码constfoldersfs.readdirSync(__dirname,{withFileTypes:true}).filter(direntdirent.isDirectory()).map(direntdirent.name);folders.forEach(folder{constfilesfs.readdirSync(path.join(__dirname,folder));if(files.includes(${folder}.png)files.includes(${folder}.txt)){agents.push({name:folder,prompt:fs.readFileSync(path.join(__dirname,folder,${folder}.txt),utf8),image:/agents/${folder}/${folder}.png});}});这个方案验证了“以边界为锚”——每个智能体的边界就是它的文件夹。数据和代码分离边界清晰维护成本骤降。4.4 TypeWell以边界为锚的另一个角度TypeWell是智能键盘健康教练。核心功能实时监听按键用热力图可视化手指使用频率。性能问题是最大的挑战。键盘监听每秒触发几十次如果每次更新都重新计算所有按键CPU扛不住。解法是“增量更新”——只更新变化的按键。letlastHeatMapnewMap();functionupdateAllHeat(){keyElements.forEach(keyDiv{constkeyNamekeyDiv.dataset.key;constoldHeatlastHeatMap.get(keyName)||0;constnewHeatheatMap.get(keyName)||0;if(oldHeat!newHeat){updateSingleKey(keyDiv,newHeat);}});lastHeatMapnewMap(heatMap);}边界划清楚了——只更新变化的按键。那些没变的不用管。这也是“以边界为锚”的体现。4.5 BounceChat在取舍间平衡BounceChat是物理桌面小球。需要物理引擎、窗口识别、AI对话。如果追求极致性能应该用C写物理引擎。如果追求极致UI应该用React重写前端。但最后选了Python 前端三件套。为什么因为在这个场景下Python的性能够用前端三件套的灵活性够用。不是最优解是最合适的解。这就是“在取舍间平衡”——资源有限找当下最优解。4.6 FileVibe从结果倒推FileVibe是文件加密AI解读工具。核心是AES-256-CBC加密。每个加密决策都是从目标结果倒推出来的需要文件加密存储 → 选AES-256用户输入的是密码 → 需要用SHA-256生成32字节密钥相同明文不能有相同密文 → 需要用随机IVIV不能丢 → IV拼接在密文前面一起存储functionencryptBuffer(buffer,password){constkeygenerateKey(password);constivcrypto.randomBytes(16);constciphercrypto.createCipheriv(aes-256-cbc,Buffer.from(key),iv);constencryptedBuffer.concat([cipher.update(buffer),cipher.final()]);returnBuffer.concat([iv,encrypted]);}每一步都有理由每一个理由都是从结果倒推出来的。4.7 五个项目的共同点五个项目技术栈不同、功能不同、复杂度不同。但有一个共同点都是“后端语言 前端三件套”的混合架构。Python做重活HTML/CSS/JS做界面。Node.js做全栈前端三件套做交互。不是刻意为之。是做着做着发现这是最小作用量的选择。用已经会的技术解决需要解决的问题。不炫技不追新不把简单问题复杂化。第五章展板——方法论选手的“实物”5.1 我的展位上有什么一块KT板一台笔记本电脑。KT板上写着三个思维模型五个项目名称一个结论。笔记本电脑里跑着五个项目的代码。没有电机声没有指示灯闪烁没有能摸的零件。只有一个高二学生站在展位前指着屏幕说“您看这个文件夹结构就是边界锚定的体现。”说实话我自己都觉得有点抽象。5.2 展板上的字展板上的字不多三个思维模型以边界为锚——告诉系统“做到这里就够了”从结果倒推——先想清楚“要什么”再找技术在取舍间平衡——资源有限找“当下最优解”五个项目验证MultiMind → 以边界为锚TypeWell → 以边界为锚BounceChat → 在取舍间平衡FileVibe → 从结果倒推青简问对 → 反面案例→正解演进研究结论技术决策能力只能在真实项目中“长出来”无法靠“拿来”获得。就这么多了。剩下的用嘴说。5.3 展板不能写的东西布展指南第8条内容中不得出现指导教师姓名、专家评价、媒体报道材料、以往获奖情况……所以我不能把他们的名字写在KT板上。第六章赛前——四天倒计时6.1 第一天查漏把论文从头到尾翻了一遍。不是检查错误是想确认一件事这些东西我真的想明白了吗结论是大部分想明白了。还有一小部分可能要等以后再来回答。6.2 第二天演练对着空房间讲了三遍。第一遍磕磕绊绊第二遍顺畅了一些第三遍终于不用看稿子。但我知道到了现场面对评委可能还会磕巴。没关系磕巴了就重来。6.3 第三天做展板把打印好的素材拿出来按设计图摆好。KT板还没贴等到了现场再动手。看着那些字突然觉得有点不真实。这些东西真的要贴到展板上去了。6.4 第四天出发四月二十三日巴蜀中学。地下运动场。隔壁展位可能摆着智能垃圾桶。我展位上只有一块KT板和一台笔记本。谁更创新我不知道。但我知道我能站在这里就是因为这些东西。那些文章、那些项目、那些踩过的坑都是真的。第七章如果评委问我7.1 “你怎么证明这个方法论有用”您看我本人就是证据。一个不会焊电路的高中生从“借来的判断”走到“自己的判断”。这不就是最好的验证吗7.2 “你的作品和隔壁的智能垃圾桶比谁更创新”我不知道。但我知道我能站在这里就是因为这些东西。那些文章、那些项目、那些踩过的坑都是真的。创新不是比赛是过程。我走完了这个过程这就够了。7.3 “你写这么多文章有人看吗求点赞收藏关注”有的。不然我也不会站在这里。那些点赞、收藏、评论那些Gitee上的star和fork那些私信里说“看了你的文章我也有思路了”——这些都是真的。我写的字有人读完了。后记写这篇随笔的时候我还没去巴蜀。不知道评委会不会问“你这个有什么用”。不知道隔壁展位会不会比我讲得精彩。不知道自己的展板会不会贴歪。不知道电脑会不会在现场蓝屏。这些都不知道。但我知道一件事那些文章、那些项目、那些踩过的坑都是真的。我不是在证明什么。我是在记录。记录一个不会焊电路的人从“借来的判断”走到“自己的判断”的过程。四月二十三日巴蜀中学。不来也没关系。文章都在CSDN上代码都在Gitee里。看完觉得有用的点个赞。觉得没用的也没关系。毕竟判断力这东西不是看出来的是做出来的。