会议室里多了一张流程图。
不是概念，不是畅想，而是清清楚楚的甘特图，时间线被压缩得很紧，像一条被拉到极限的橡皮筋。
“小说阅读器项目，正式立项。”
陈浩的声音不高，却很干脆。
林晨抬头的瞬间，心里反而安静了下来。
他早就预感到，这件事不会停在“技术预研”。
“业务目标很明确，”陈浩继续说，“不是试水，是上线，是对外。”
PPT 翻到下一页。
项目负责人：苏雨****
前端负责人：林晨****
名单就这么摆在那儿，没有多余解释。
苏雨站在桌子另一侧，朝他看了一眼，很短暂，却没有回避。
他们都明白这意味着什么——
之前的分歧，现在要变成日常。
会议进入需求阶段。
“阅读器的核心不是功能多，”
苏雨说，“而是读得久、看得舒服。”
她没有重复上次预研时的那些概念，而是直接落到了执行层。
“首屏必须快。”
“翻页不能卡。”
“设置项再多，也不能影响正文流畅。”
林晨一边听，一边在本子上写。
不是记需求，是在拆。
首屏快，对应的是 首次内容渲染；
翻页流畅，对应的是 DOM 更新粒度；
设置不影响正文，本质是 状态隔离。
这些词，他没有说出来。
他知道，现在不是技术辩论的时间。
轮到前端评估时，林晨只说了一句话：
“这个项目，需要前端提前介入设计。”
不是请求，是判断。
会议室里有人皱眉。
“什么意思？”
项目经理张明问。
“不是等原型定完再开发，”林晨解释，“有些交互，一旦画死，技术上就只能妥协。”
他停了一下，补了一句：
“不是做不了，是会留下隐患。”
苏雨没有反驳。
她只是点了点头：“那我希望你能明确告诉我，哪些地方是‘不能画’的。”
这是她第一次，把边界交出来。
会后，两人被拉进了同一个项目群。
群名很简单：
Reader-v1****
林晨盯着那个名字看了一会儿，才点开需求文档。
他没有立刻挑刺，而是先在最上面加了一行备注：
前端风险点汇总（持续更新）****
第一条，他写得很克制：
章节渲染策略需在原型阶段确认，否则后期性能不可控。
这不是抱怨，是预警。
傍晚，苏雨在文档里 @ 了他。
你说的“不可控”，具体指什么？
林晨想了几秒，没有打字。
他直接发了一段代码。
// 假设：每章平均 20 个段落
// 300 章 ≈ 6000 个 DOM 节点（不含图片）
然后补了一句话：
当设置项变化触发全量更新时，浏览器不会管这是“阅读体验”，它只会重算。
苏雨很久才回。
明白了。
那我们原型里，章节之间的“无缝滚动”先不强制。
林晨靠在椅子上，轻轻呼了一口气。
不是胜利。
是第一次协作成功。
晚上十点，办公室只剩零星几个人。
林晨开始真正搭项目骨架。
// Reader App Root
// 原则：数据驱动视图，但不放任依赖扩散
他没有急着写复杂逻辑，只搭了最基础的结构。
Vue、状态拆分、模块边界。
这一次，他不是在“写一个功能”，
而是在为一个会被反复修改的产品做准备。
临走前，苏雨发来一条消息。
我发现你们工程思考问题的方式，和我想象的不太一样。
林晨回得很慢。
我们只是更早看到代价。
对话停在这里。
没有多余寒暄，也没有情绪升温。
但某种看不见的关系，已经被锁定在同一个项目里。
他们都知道——
接下来，不会轻松了。
