赛前随笔：重庆市青创赛，一个方法论选手的碎碎念

赛前随笔：重庆市青创赛决赛，一个方法论选手的碎碎念

本文的方法论均可在 边界之内：技术人的决策框架 查阅，欢迎订阅

四月十九日。离出发还有四天。
桌上摊着论文、展板草稿、笔记本电脑，还有一杯凉透的茶。
窗外有鸟叫，阳光很好，但我不想开窗。
一开窗，楼下广场舞的声音就会涌进来，打断脑子里那根绷了太久的弦。
其实没什么好紧张的。稿子背熟了，项目跑稳了，展板素材也打印好了。
可心里就是空落落的，像考试前突然发现自己漏背了一整章——虽然那一章可能根本不考。
我到底是怎么进来的？

第一章：起点——一个不会焊电路的人

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。

新增智能体 = 新建文件夹。移除智能体 = 删除文件夹。系统启动时扫描目录，动态加载所有智能体。

核心逻辑只有十几行代码：

constfolders=fs.readdirSync(__dirname,{withFileTypes:true}).filter(dirent=>dirent.isDirectory()).map(dirent=>dirent.name);folders.forEach(folder=>{constfiles=fs.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扛不住。

解法是“增量更新”——只更新变化的按键。

letlastHeatMap=newMap();functionupdateAllHeat(){keyElements.forEach(keyDiv=>{constkeyName=keyDiv.dataset.key;constoldHeat=lastHeatMap.get(keyName)||0;constnewHeat=heatMap.get(keyName)||0;if(oldHeat!==newHeat){updateSingleKey(keyDiv,newHeat);}});lastHeatMap=newMap(heatMap);}

边界划清楚了——只更新变化的按键。那些没变的，不用管。这也是“以边界为锚”的体现。

4.5 BounceChat：在取舍间平衡

BounceChat是物理桌面小球。需要物理引擎、窗口识别、AI对话。

如果追求极致性能，应该用C++写物理引擎。如果追求极致UI，应该用React重写前端。但最后选了Python + 前端三件套。

为什么？因为在这个场景下，Python的性能够用，前端三件套的灵活性够用。不是最优解，是最合适的解。

这就是“在取舍间平衡”——资源有限，找当下最优解。

4.6 FileVibe：从结果倒推

FileVibe是文件加密+AI解读工具。核心是AES-256-CBC加密。

每个加密决策都是从目标结果倒推出来的：

• 需要文件加密存储 → 选AES-256
• 用户输入的是密码 → 需要用SHA-256生成32字节密钥
• 相同明文不能有相同密文 → 需要用随机IV
• IV不能丢 → IV拼接在密文前面一起存储

functionencryptBuffer(buffer,password){constkey=generateKey(password);constiv=crypto.randomBytes(16);constcipher=crypto.createCipheriv('aes-256-cbc',Buffer.from(key),iv);constencrypted=Buffer.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里。

看完觉得有用的，点个赞。觉得没用的，也没关系。毕竟，判断力这东西，不是看出来的，是做出来的。