Subscribed successfully
Node.js Blog
Node.js Blog
让 AI 戴着镣铐跳舞
最近临时在帮朋友做一些外包，基本上代码都是 AI 写的，我想如果不是有 AI, 我大概不会帮这个忙，因为即使这些活不难，我还是要写很多代码。但现在，我可以一个人同时做 2-3 个项目。
在这个过程中，更加让我确定了对于程序员来说，软件开发的范式已经彻底彻底改变了。生成代码再也不是程序员「应该」做的事情，而是应该被放手给 AI 做的事。
这也让我对判断一个程序员的能力从代码能力转变成了使用 AI 的能力，我想，如果我现在要为团队招程序员，我会在面试时着重了解这个人如何使用 AI 完成一个需求。
对于程序员来说，「使用 AI 的能力」包含很多维度，这些维度综合起来，才决定 AI 是否真正能成为程序员的杠杆：
对业务的理解
软件是为解决用户的需求而生的，对业务充分理解，才能给 AI 足够的业务场景上下文，才能让 AI 写出覆盖边界条件的代码。
对业务的理解同时决定了程序员是否可以做好数据库建模。在接我朋友的外包项目时，我发现我人工干预最多的就是数据库建模。只要我思考好建模，AI 就能基于这个数据库模型编写任何接口。
对技术栈的理解
如果能让 AI 限定在特定的技术栈中，你会发现 AI 更能稳定发挥，更可控。让 AI 「带着镣铐跳舞」。无论用什么技术栈，重点都是给 AI 一条稳定的轨道。比如我在所有项目的 AGENT.md 中都会列出非常细节的选型，例如 CC Mate 的 https://github.com/djyde/ccmate/blob/main/CLAUDE.md
当 AI 知道技术栈后，通过 context7 这样的 MCP, 它能在生成代码时，找到对应的文档作为上下文，生成出更不容易出错的代码。换句话说，确定好技术栈，让 AI 成为这个技术栈的专家为你编写代码。
因此，在这个层面，程序员的「使用 AI 的能力」意味着，这个程序员知道什么样的场景适合什么样的技术栈，也侧面反映了这个程序员对技术社区是否保持敏锐的嗅觉。这是我认为 AI 时代程序员的一种硬实力。
对架构的理解
在《代码之外》听友线下见面会中，有听友提问，在 vibe coding 的时候，AI 只能做些一次性的软件，多次迭代后就会变成灾难。我的回答是，这是因为没有给 AI 提供一个你设计好的工程架构，让他在这个架构中行动。在这个新的时代，程序员应该以架构师的角度来工作。
我在 AI coding 一个项目前，我的脑海里会大概有一个工程架构的设计，比如，通用工具应该被统一放到一个什么文件，前端页面应该如何组织，接口应该遵循什么样的规范，错误处理应该怎么做等等。只要架构设计好，写在 AGENT.md 中，AI 自然会按照你的设计去做，而不是让 AI 天马行空地发挥。
不仅是在启动这个项目前要做好架构的思考，在维护的过程中，你指挥 AI 完成一个新的需求时，就应该思考完成这个需求的时候，将会有什么代码被写在哪一个地方。这个场景也适合使用各个 AI coding agent 的 Plan Mode 来完成，当 AI 告诉你它将要如何行动时，适当二次确认它要如何组织新的代码。
做到以上三个理解，我相信程序员可以游刃有余地使用 AI. 但我曾经在很多场合接触一些在一线写代码的程序员，发现他们对 AI 的接受程度是如此地低。很大程度上，我认为是一个缺乏以上三个理解的程序员，很难对 AI 建立信任关系，合作关系。
和我合作的一位程序员，在共同完成一个需求的时候，我在他旁边观察了一下他如何使用 AI, 结果只是非常浅地使用 auto complete. 我问他，为什么不尝试让 AI 完整地完成这个需求，他表示他认为 AI 不能胜任这个任务。
我说：
1. 我的后端接口已经写好了，而且有了 openapi 的 YAML 文件（AI 生成的）
2. 你知道这个需求涉及前端的哪个页面，在前端项目中，也有对数据请求层进行封装（AI 一定能知道怎么写数据请求）
满足了这两个条件，你只需要把接口文档给 AI, 然后告诉 AI 这次的需求，再告诉 AI 一点提示，大概是在哪个文件中修改。以现在旗舰模型的能力，AI 大概率能一次性完成。
他将信将疑，我直接在他电脑上给他演示这个操作，果然，AI 直接完美地完成了这个需求，不到 2 分钟。
而同时我也在思考，到底 AI 时代是否还需要程序员，或说需要怎样的程序员，好像渐渐有了答案。
via Randy's Blog
最近临时在帮朋友做一些外包，基本上代码都是 AI 写的，我想如果不是有 AI, 我大概不会帮这个忙，因为即使这些活不难，我还是要写很多代码。但现在，我可以一个人同时做 2-3 个项目。
在这个过程中，更加让我确定了对于程序员来说，软件开发的范式已经彻底彻底改变了。生成代码再也不是程序员「应该」做的事情，而是应该被放手给 AI 做的事。
这也让我对判断一个程序员的能力从代码能力转变成了使用 AI 的能力，我想，如果我现在要为团队招程序员，我会在面试时着重了解这个人如何使用 AI 完成一个需求。
对于程序员来说，「使用 AI 的能力」包含很多维度，这些维度综合起来，才决定 AI 是否真正能成为程序员的杠杆：
对业务的理解
软件是为解决用户的需求而生的，对业务充分理解，才能给 AI 足够的业务场景上下文，才能让 AI 写出覆盖边界条件的代码。
对业务的理解同时决定了程序员是否可以做好数据库建模。在接我朋友的外包项目时，我发现我人工干预最多的就是数据库建模。只要我思考好建模，AI 就能基于这个数据库模型编写任何接口。
对技术栈的理解
如果能让 AI 限定在特定的技术栈中，你会发现 AI 更能稳定发挥，更可控。让 AI 「带着镣铐跳舞」。无论用什么技术栈，重点都是给 AI 一条稳定的轨道。比如我在所有项目的 AGENT.md 中都会列出非常细节的选型，例如 CC Mate 的 https://github.com/djyde/ccmate/blob/main/CLAUDE.md
当 AI 知道技术栈后，通过 context7 这样的 MCP, 它能在生成代码时，找到对应的文档作为上下文，生成出更不容易出错的代码。换句话说，确定好技术栈，让 AI 成为这个技术栈的专家为你编写代码。
因此，在这个层面，程序员的「使用 AI 的能力」意味着，这个程序员知道什么样的场景适合什么样的技术栈，也侧面反映了这个程序员对技术社区是否保持敏锐的嗅觉。这是我认为 AI 时代程序员的一种硬实力。
对架构的理解
在《代码之外》听友线下见面会中，有听友提问，在 vibe coding 的时候，AI 只能做些一次性的软件，多次迭代后就会变成灾难。我的回答是，这是因为没有给 AI 提供一个你设计好的工程架构，让他在这个架构中行动。在这个新的时代，程序员应该以架构师的角度来工作。
我在 AI coding 一个项目前，我的脑海里会大概有一个工程架构的设计，比如，通用工具应该被统一放到一个什么文件，前端页面应该如何组织，接口应该遵循什么样的规范，错误处理应该怎么做等等。只要架构设计好，写在 AGENT.md 中，AI 自然会按照你的设计去做，而不是让 AI 天马行空地发挥。
不仅是在启动这个项目前要做好架构的思考，在维护的过程中，你指挥 AI 完成一个新的需求时，就应该思考完成这个需求的时候，将会有什么代码被写在哪一个地方。这个场景也适合使用各个 AI coding agent 的 Plan Mode 来完成，当 AI 告诉你它将要如何行动时，适当二次确认它要如何组织新的代码。
做到以上三个理解，我相信程序员可以游刃有余地使用 AI. 但我曾经在很多场合接触一些在一线写代码的程序员，发现他们对 AI 的接受程度是如此地低。很大程度上，我认为是一个缺乏以上三个理解的程序员，很难对 AI 建立信任关系，合作关系。
和我合作的一位程序员，在共同完成一个需求的时候，我在他旁边观察了一下他如何使用 AI, 结果只是非常浅地使用 auto complete. 我问他，为什么不尝试让 AI 完整地完成这个需求，他表示他认为 AI 不能胜任这个任务。
我说：
1. 我的后端接口已经写好了，而且有了 openapi 的 YAML 文件（AI 生成的）
2. 你知道这个需求涉及前端的哪个页面，在前端项目中，也有对数据请求层进行封装（AI 一定能知道怎么写数据请求）
满足了这两个条件，你只需要把接口文档给 AI, 然后告诉 AI 这次的需求，再告诉 AI 一点提示，大概是在哪个文件中修改。以现在旗舰模型的能力，AI 大概率能一次性完成。
他将信将疑，我直接在他电脑上给他演示这个操作，果然，AI 直接完美地完成了这个需求，不到 2 分钟。
而同时我也在思考，到底 AI 时代是否还需要程序员，或说需要怎样的程序员，好像渐渐有了答案。
via Randy's Blog
回头看见自己
前几天收到通知，所在的团队解散了，我这段工作也一起画上句号。
虽然这个月一直隐隐觉得情况不太妙，但真的落在自己身上的那一刻，人还是会愣一下。有点空，有点失落，也有种「啊，原来已经走到这一步了」的感觉。
想了几天，还是决定把这一年多的经历和一些个人反思写下来，当作一个存档。以后哪天心态稳定了，再回头看，至少能更清楚地知道自己这段时间到底经历了什么、学到了什么。
为什么会去做这个项目
最早接到这个机会时，我刚经历人生第一次裁员。那段时间整个人状态挺糟的，对未来特别迷茫，对自己也没什么信心，各种躯体反应、抑郁、焦虑、失眠一股脑地冒出来。
就在那时候，有人找我聊到这个项目。那会儿项目还非常早期，很多东西都停留在想法、脑图和讨论里，连像样的 demo 都还没有。但对当时的我来说，有人愿意拉我一把，给我一个能重新把注意力投进去的事情，本身就挺不一样的。
现在回头看这段经历，哪怕后来大家的路径和选择各不相同，我依然很感谢当时那次「拉一把」。它确实是在我比较低谷的一个时间点，给了我一个出口。
另一方面就是一个很简单的判断：我本身就对这种类别的产品很感兴趣。
我一直喜欢做 ToC 的产品，喜欢琢磨交互细节、体验和界面呈现。
再一次从零开始创造一个东西，其实是很酷的事情，而且自由度也很高。这个项目在早期也给了我很多发挥空间。
在这一年多里，我都在做些什么
如果只看事情本身，这一年多其实过得很密。
因为项目很早期，很多基础的东西都需要从头搭起来，我主要做了这些：
● 从零搭了一整套基础组件；
● 一点点把 UI 的设计规则、风格和设计体系搭出来；
● 把 App 的数据流架构重新理了一遍，把之前比较散的部分串起来；
● 桌面端（Electron）的更新方案、一些踩坑和调优，也是我一点点摸出来的；
● 围绕产品的设计和优化，我也写过几篇博客记录当时的想法。
那段时间，我基本是 设计、前端、产品 三件事一起干。经常是白天写代码、改交互，晚上还在想组件要不要再重构一下，周末偶尔继续打磨。
我对细节的执着，在那个阶段被放大得很明显。经常为了一个 1px 的对齐，或者一个 hover 状态，盯着屏幕看半天，不停调 spacing，调整节奏。
后面我的 commit 数一直往上爬，前端那块几乎所有角落都翻过一遍，一些历史遗留的问题也是趁着重构的时候顺手清。
有人跟我说，我这状态有点像把公司项目做成了个人项目。虽然有点玩笑的成分，但确实说明了当时那种「恨不得所有细节都先过一遍我眼睛」的投入。
从纯工程师视角看，这一年我学到的东西挺多的。
以前更多是「完成别人安排的需求」，现在多少对这个产品的形状、系统架构、体验节奏，有了一些自己的判断。
对这段经历的一些个人反思
接下来这部分，就不局限在这个项目本身了，更多是我在这段时间里，对「怎么做一个产品」的一些感受。
我不打算给任何人下结论，只讲我自己以后会怎么做得不一样。
1. 关于「商业化要不要想得很早」
在早期阶段，我确实更偏向「先把东西做出来」「先做一个好玩的产品」，对商业化的思考会往后放。事后回头看，对我自己来说，教训是：
现在再做任何项目，只要心里有一点「它有机会变成一个长期产品」的念头，我都会尽量在比较早的阶段，先粗略想清楚：
● 它大概会服务谁；
● 这些人为什么会愿意长期留下来；
● 他们愿意为什么买单。
这不只是这次经历的感受，其实是这几年所有项目叠加起来给我的提醒。
2. 关于「激励」和「真正的用户」
另一个对我很深的提醒是：激励是一种筛选器。
各种奖励、玩法，在短期内都非常有效，这点我在这个项目以及别的一些项目里都见过。
但它筛出来的，更多是「对激励敏感的人」，而不一定是「对产品本身有强需求的人」。
如果前期一直用这种方式去拉新，很容易导致：
● 数据好看、热度不低；
● 但当你希望产品靠长期价值站住时，发现核心人群其实没有被真正建立起来。
以后再做类似的产品，我会更谨慎地区分：
● 哪些是「为产品本身添砖加瓦」的设计；
● 哪些只是「为了短期刺激」的玩法。
这个反思同样不是在评价哪个项目好或不好，而是提醒自己：
不能只被短期数字牵着走，要时刻记住自己真正希望留下的那一拨人是谁。
3. 方向没想清楚的时候，越努力反而越危险
这段经历里，还有一个挺扎心的感受：
4. 时机本身也是一种成本
这几年回头看，会有一个很强的感觉：
● 要不要在那时候认真规划一下下一阶段；
● 要不要借着关注度去争取更多缓冲时间；
后来的剧本可能会不太一样。当然，也未必就一定成功，但至少不是在热度退去之后再来补前面的课。
这件事给我的提醒是：
● 产品有自己的节奏；
● 市场也有它的节奏；
● 有些决定，如果总觉得「以后再说」，其实就是一种隐性成本。
关于「人情」这部分
前面说了很多产品、商业、技术上的东西，但对我个人来说，这段经历还有一块很重要的是「人」。
● 在我第一次被裁、状态很差的时候，是这个项目给了我一个可以重新投入的方向；
● 给了我一个在桌面端、大型 ToC 产品上深度打磨的机会；
● 也让我有机会接触到之前没做到的职责和领域。
不管后来每个人的选择如何，这件事本身我是一直记在心里的。
有时候就是这样。你在别人低谷的时候伸一把手，对那个人来说，意义会很长。
所以，对这段经历，我的情绪是很复杂的：
● 有遗憾，也有不甘心；
● 但也有很多真诚的感谢。
它既不是简单的「成功」或「失败」两个字可以概括的，更像是一次把很多课提前塞给我的密集训练。
对未来的一点想法
短期内，要面对的还是很现实的问题。找下一份工作，解决生活，慢慢让自己从这段紧绷的节奏里抽离出来。
但可以确定的是，以后再谈「做一个可持续的产品」，我的态度会比以前更加谨慎，也会多一点敬畏。
如果你刚好也在经历类似的阶段，或者也在做一个早期项目，希望这些碎碎念能给你一点参考。哪怕只是让你提前避开我走过的一两个坑，也算是这段经历留下的价值之一。
谢谢你看到这里。
看完了？说点什么呢
via 静かな森 (author: Innei)
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://innei.in/posts/experience/looking-back-at-myself
前几天收到通知，所在的团队解散了，我这段工作也一起画上句号。
虽然这个月一直隐隐觉得情况不太妙，但真的落在自己身上的那一刻，人还是会愣一下。有点空，有点失落，也有种「啊，原来已经走到这一步了」的感觉。
想了几天，还是决定把这一年多的经历和一些个人反思写下来，当作一个存档。以后哪天心态稳定了，再回头看，至少能更清楚地知道自己这段时间到底经历了什么、学到了什么。
为什么会去做这个项目
最早接到这个机会时，我刚经历人生第一次裁员。那段时间整个人状态挺糟的，对未来特别迷茫，对自己也没什么信心，各种躯体反应、抑郁、焦虑、失眠一股脑地冒出来。
就在那时候，有人找我聊到这个项目。那会儿项目还非常早期，很多东西都停留在想法、脑图和讨论里，连像样的 demo 都还没有。但对当时的我来说，有人愿意拉我一把，给我一个能重新把注意力投进去的事情，本身就挺不一样的。
现在回头看这段经历，哪怕后来大家的路径和选择各不相同，我依然很感谢当时那次「拉一把」。它确实是在我比较低谷的一个时间点，给了我一个出口。
另一方面就是一个很简单的判断：我本身就对这种类别的产品很感兴趣。
我一直喜欢做 ToC 的产品，喜欢琢磨交互细节、体验和界面呈现。
再一次从零开始创造一个东西，其实是很酷的事情，而且自由度也很高。这个项目在早期也给了我很多发挥空间。
在这一年多里，我都在做些什么
如果只看事情本身，这一年多其实过得很密。
因为项目很早期，很多基础的东西都需要从头搭起来，我主要做了这些：
● 从零搭了一整套基础组件；
● 一点点把 UI 的设计规则、风格和设计体系搭出来；
● 把 App 的数据流架构重新理了一遍，把之前比较散的部分串起来；
● 桌面端（Electron）的更新方案、一些踩坑和调优，也是我一点点摸出来的；
● 围绕产品的设计和优化，我也写过几篇博客记录当时的想法。
那段时间，我基本是 设计、前端、产品 三件事一起干。经常是白天写代码、改交互，晚上还在想组件要不要再重构一下，周末偶尔继续打磨。
我对细节的执着，在那个阶段被放大得很明显。经常为了一个 1px 的对齐，或者一个 hover 状态，盯着屏幕看半天，不停调 spacing，调整节奏。
后面我的 commit 数一直往上爬，前端那块几乎所有角落都翻过一遍，一些历史遗留的问题也是趁着重构的时候顺手清。
有人跟我说，我这状态有点像把公司项目做成了个人项目。虽然有点玩笑的成分，但确实说明了当时那种「恨不得所有细节都先过一遍我眼睛」的投入。
从纯工程师视角看，这一年我学到的东西挺多的。
以前更多是「完成别人安排的需求」，现在多少对这个产品的形状、系统架构、体验节奏，有了一些自己的判断。
对这段经历的一些个人反思
接下来这部分，就不局限在这个项目本身了，更多是我在这段时间里，对「怎么做一个产品」的一些感受。
我不打算给任何人下结论，只讲我自己以后会怎么做得不一样。
1. 关于「商业化要不要想得很早」
在早期阶段，我确实更偏向「先把东西做出来」「先做一个好玩的产品」，对商业化的思考会往后放。事后回头看，对我自己来说，教训是：
不一定一开始就要把每一块都推到极致，但至少要在心里留一条大致的路： 这个产品大概是为谁做的，这些人未来有没有「愿意为它长期买单」的可能。如果脑子里完全没有这条路，日常决策就很容易被短期数据牵着走。很多看上去漂亮的增长，不一定是在为未来打基础，有时候只是让你在一条不太适合长期生存的路径上走得更远。
现在再做任何项目，只要心里有一点「它有机会变成一个长期产品」的念头，我都会尽量在比较早的阶段，先粗略想清楚：
● 它大概会服务谁；
● 这些人为什么会愿意长期留下来；
● 他们愿意为什么买单。
这不只是这次经历的感受，其实是这几年所有项目叠加起来给我的提醒。
2. 关于「激励」和「真正的用户」
另一个对我很深的提醒是：激励是一种筛选器。
各种奖励、玩法，在短期内都非常有效，这点我在这个项目以及别的一些项目里都见过。
但它筛出来的，更多是「对激励敏感的人」，而不一定是「对产品本身有强需求的人」。
如果前期一直用这种方式去拉新，很容易导致：
● 数据好看、热度不低；
● 但当你希望产品靠长期价值站住时，发现核心人群其实没有被真正建立起来。
以后再做类似的产品，我会更谨慎地区分：
● 哪些是「为产品本身添砖加瓦」的设计；
● 哪些只是「为了短期刺激」的玩法。
这个反思同样不是在评价哪个项目好或不好，而是提醒自己：
不能只被短期数字牵着走，要时刻记住自己真正希望留下的那一拨人是谁。
3. 方向没想清楚的时候，越努力反而越危险
这段经历里，还有一个挺扎心的感受：
大家都很努力，事情也很多， 但有时候你隐约知道，自己是在用努力填前面没想清楚留下的坑。你越是全力往前冲，就越难停下来问自己一句：
如果照现在这个方向一路做到极致， 那个终点真的是我想要的吗？这个问题不针对任何人，只是对我自己的一种提醒。以后我会更刻意留出一点「按暂停键」的空间，哪怕只是定期问自己这个问题。如果长期答不上来，可能就说明有哪里不太对劲了。
4. 时机本身也是一种成本
这几年回头看，会有一个很强的感觉：
有些窗口期是真的会关上， 关上之后再做同样的事，难度完全不一样。不只是这一次，我接触过的好几个项目都有类似的影子。在某个阶段其实都迎来过一小波关注或讨论度，如果那时能更早地意识到：
● 要不要在那时候认真规划一下下一阶段；
● 要不要借着关注度去争取更多缓冲时间；
后来的剧本可能会不太一样。当然，也未必就一定成功，但至少不是在热度退去之后再来补前面的课。
这件事给我的提醒是：
● 产品有自己的节奏；
● 市场也有它的节奏；
● 有些决定，如果总觉得「以后再说」，其实就是一种隐性成本。
关于「人情」这部分
前面说了很多产品、商业、技术上的东西，但对我个人来说，这段经历还有一块很重要的是「人」。
● 在我第一次被裁、状态很差的时候，是这个项目给了我一个可以重新投入的方向；
● 给了我一个在桌面端、大型 ToC 产品上深度打磨的机会；
● 也让我有机会接触到之前没做到的职责和领域。
不管后来每个人的选择如何，这件事本身我是一直记在心里的。
有时候就是这样。你在别人低谷的时候伸一把手，对那个人来说，意义会很长。
所以，对这段经历，我的情绪是很复杂的：
● 有遗憾，也有不甘心；
● 但也有很多真诚的感谢。
它既不是简单的「成功」或「失败」两个字可以概括的，更像是一次把很多课提前塞给我的密集训练。
对未来的一点想法
短期内，要面对的还是很现实的问题。找下一份工作，解决生活，慢慢让自己从这段紧绷的节奏里抽离出来。
但可以确定的是，以后再谈「做一个可持续的产品」，我的态度会比以前更加谨慎，也会多一点敬畏。
如果你刚好也在经历类似的阶段，或者也在做一个早期项目，希望这些碎碎念能给你一点参考。哪怕只是让你提前避开我走过的一两个坑，也算是这段经历留下的价值之一。
谢谢你看到这里。
看完了？说点什么呢
via 静かな森 (author: Innei)
把这一年收进抽屉
前几天收到通知，所在的团队解散了，我这段工作也一起画上句号。
虽然这个月一直隐隐觉得情况不太妙，但真的落在自己身上的那一刻，人还是会愣一下。有点空，有点失落，也有种「啊，原来已经走到这一步了」的感觉。
想了几天，还是决定把这一年多的经历和一些个人反思写下来，当作一个存档。以后哪天心态稳定了，再回头看，至少能更清楚地知道自己这段时间到底经历了什么、学到了什么。
为什么会去做这个项目
最早接到这个机会时，我刚经历人生第一次裁员。那段时间整个人状态挺糟的，对未来特别迷茫，对自己也没什么信心，各种躯体反应、抑郁、焦虑、失眠一股脑地冒出来。
就在那时候，有人找我聊到这个项目。那会儿项目还非常早期，很多东西都停留在想法、脑图和讨论里，连像样的 demo 都还没有。但对当时的我来说，有人愿意拉我一把，给我一个能重新把注意力投进去的事情，本身就挺不一样的。
现在回头看这段经历，哪怕后来大家的路径和选择各不相同，我依然很感谢当时那次「拉一把」。它确实是在我比较低谷的一个时间点，给了我一个出口。
另一方面就是一个很简单的判断：我本身就对这种类别的产品很感兴趣。
我一直喜欢做 ToC 的产品，喜欢琢磨交互细节、体验和界面呈现。
再一次从零开始创造一个东西，其实是很酷的事情，而且自由度也很高。这个项目在早期也给了我很多发挥空间。
在这一年多里，我都在做些什么
如果只看事情本身，这一年多其实过得很密。
因为项目很早期，很多基础的东西都需要从头搭起来，我主要做了这些：
● 从零搭了一整套基础组件；
● 一点点把 UI 的设计规则、风格和设计体系搭出来；
● 把 App 的数据流架构重新理了一遍，把之前比较散的部分串起来；
● 桌面端（Electron）的更新方案、一些踩坑和调优，也是我一点点摸出来的；
● 围绕产品的设计和优化，我也写过几篇博客记录当时的想法。
那段时间，我基本是 设计、前端、产品 三件事一起干。经常是白天写代码、改交互，晚上还在想组件要不要再重构一下，周末偶尔继续打磨。
我对细节的执着，在那个阶段被放大得很明显。经常为了一个 1px 的对齐，或者一个 hover 状态，盯着屏幕看半天，不停调 spacing，调整节奏。
后面我的 commit 数一直往上爬，前端那块几乎所有角落都翻过一遍，一些历史遗留的问题也是趁着重构的时候顺手清。
有人跟我说，我这状态有点像把公司项目做成了个人项目。虽然有点玩笑的成分，但确实说明了当时那种「恨不得所有细节都先过一遍我眼睛」的投入。
从纯工程师视角看，这一年我学到的东西挺多的。
以前更多是「完成别人安排的需求」，现在多少对这个产品的形状、系统架构、体验节奏，有了一些自己的判断。
对这段经历的一些个人反思
接下来这部分，就不局限在这个项目本身了，更多是我在这段时间里，对「怎么做一个产品」的一些感受。
我不打算给任何人下结论，只讲我自己以后会怎么做得不一样。
1. 关于「商业化要不要想得很早」
在早期阶段，我确实更偏向「先把东西做出来」「先做一个好玩的产品」，对商业化的思考会往后放。事后回头看，对我自己来说，教训是：
现在再做任何项目，只要心里有一点「它有机会变成一个长期产品」的念头，我都会尽量在比较早的阶段，先粗略想清楚：
● 它大概会服务谁；
● 这些人为什么会愿意长期留下来；
● 他们愿意为什么买单。
这不只是这次经历的感受，其实是这几年所有项目叠加起来给我的提醒。
2. 关于「激励」和「真正的用户」
另一个对我很深的提醒是：激励是一种筛选器。
各种奖励、玩法，在短期内都非常有效，这点我在这个项目以及别的一些项目里都见过。
但它筛出来的，更多是「对激励敏感的人」，而不一定是「对产品本身有强需求的人」。
如果前期一直用这种方式去拉新，很容易导致：
● 数据好看、热度不低；
● 但当你希望产品靠长期价值站住时，发现核心人群其实没有被真正建立起来。
以后再做类似的产品，我会更谨慎地区分：
● 哪些是「为产品本身添砖加瓦」的设计；
● 哪些只是「为了短期刺激」的玩法。
这个反思同样不是在评价哪个项目好或不好，而是提醒自己：
不能只被短期数字牵着走，要时刻记住自己真正希望留下的那一拨人是谁。
3. 方向没想清楚的时候，越努力反而越危险
这段经历里，还有一个挺扎心的感受：
4. 时机本身也是一种成本
这几年回头看，会有一个很强的感觉：
● 要不要在那时候认真规划一下下一阶段；
● 要不要借着关注度去争取更多缓冲时间；
后来的剧本可能会不太一样。当然，也未必就一定成功，但至少不是在热度退去之后再来补前面的课。
这件事给我的提醒是：
● 产品有自己的节奏；
● 市场也有它的节奏；
● 有些决定，如果总觉得「以后再说」，其实就是一种隐性成本。
关于「人情」这部分
前面说了很多产品、商业、技术上的东西，但对我个人来说，这段经历还有一块很重要的是「人」。
● 在我第一次被裁、状态很差的时候，是这个项目给了我一个可以重新投入的方向；
● 给了我一个在桌面端、大型 ToC 产品上深度打磨的机会；
● 也让我有机会接触到之前没做到的职责和领域。
不管后来每个人的选择如何，这件事本身我是一直记在心里的。
有时候就是这样。你在别人低谷的时候伸一把手，对那个人来说，意义会很长。
所以，对这段经历，我的情绪是很复杂的：
● 有遗憾，也有不甘心；
● 但也有很多真诚的感谢。
它既不是简单的「成功」或「失败」两个字可以概括的，更像是一次把很多课提前塞给我的密集训练。
对未来的一点想法
短期内，要面对的还是很现实的问题。找下一份工作，解决生活，慢慢让自己从这段紧绷的节奏里抽离出来。
但可以确定的是，以后再谈「做一个可持续的产品」，我的态度会比以前更加谨慎，也会多一点敬畏。
如果你刚好也在经历类似的阶段，或者也在做一个早期项目，希望这些碎碎念能给你一点参考。哪怕只是让你提前避开我走过的一两个坑，也算是这段经历留下的价值之一。
谢谢你看到这里。
看完了？说点什么呢
via 静かな森 (author: Innei)
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://innei.in/posts/experience/put-this-year-in-a-drawer
前几天收到通知，所在的团队解散了，我这段工作也一起画上句号。
虽然这个月一直隐隐觉得情况不太妙，但真的落在自己身上的那一刻，人还是会愣一下。有点空，有点失落，也有种「啊，原来已经走到这一步了」的感觉。
想了几天，还是决定把这一年多的经历和一些个人反思写下来，当作一个存档。以后哪天心态稳定了，再回头看，至少能更清楚地知道自己这段时间到底经历了什么、学到了什么。
为什么会去做这个项目
最早接到这个机会时，我刚经历人生第一次裁员。那段时间整个人状态挺糟的，对未来特别迷茫，对自己也没什么信心，各种躯体反应、抑郁、焦虑、失眠一股脑地冒出来。
就在那时候，有人找我聊到这个项目。那会儿项目还非常早期，很多东西都停留在想法、脑图和讨论里，连像样的 demo 都还没有。但对当时的我来说，有人愿意拉我一把，给我一个能重新把注意力投进去的事情，本身就挺不一样的。
现在回头看这段经历，哪怕后来大家的路径和选择各不相同，我依然很感谢当时那次「拉一把」。它确实是在我比较低谷的一个时间点，给了我一个出口。
另一方面就是一个很简单的判断：我本身就对这种类别的产品很感兴趣。
我一直喜欢做 ToC 的产品，喜欢琢磨交互细节、体验和界面呈现。
再一次从零开始创造一个东西，其实是很酷的事情，而且自由度也很高。这个项目在早期也给了我很多发挥空间。
在这一年多里，我都在做些什么
如果只看事情本身，这一年多其实过得很密。
因为项目很早期，很多基础的东西都需要从头搭起来，我主要做了这些：
● 从零搭了一整套基础组件；
● 一点点把 UI 的设计规则、风格和设计体系搭出来；
● 把 App 的数据流架构重新理了一遍，把之前比较散的部分串起来；
● 桌面端（Electron）的更新方案、一些踩坑和调优，也是我一点点摸出来的；
● 围绕产品的设计和优化，我也写过几篇博客记录当时的想法。
那段时间，我基本是 设计、前端、产品 三件事一起干。经常是白天写代码、改交互，晚上还在想组件要不要再重构一下，周末偶尔继续打磨。
我对细节的执着，在那个阶段被放大得很明显。经常为了一个 1px 的对齐，或者一个 hover 状态，盯着屏幕看半天，不停调 spacing，调整节奏。
后面我的 commit 数一直往上爬，前端那块几乎所有角落都翻过一遍，一些历史遗留的问题也是趁着重构的时候顺手清。
有人跟我说，我这状态有点像把公司项目做成了个人项目。虽然有点玩笑的成分，但确实说明了当时那种「恨不得所有细节都先过一遍我眼睛」的投入。
从纯工程师视角看，这一年我学到的东西挺多的。
以前更多是「完成别人安排的需求」，现在多少对这个产品的形状、系统架构、体验节奏，有了一些自己的判断。
对这段经历的一些个人反思
接下来这部分，就不局限在这个项目本身了，更多是我在这段时间里，对「怎么做一个产品」的一些感受。
我不打算给任何人下结论，只讲我自己以后会怎么做得不一样。
1. 关于「商业化要不要想得很早」
在早期阶段，我确实更偏向「先把东西做出来」「先做一个好玩的产品」，对商业化的思考会往后放。事后回头看，对我自己来说，教训是：
不一定一开始就要把每一块都推到极致，但至少要在心里留一条大致的路： 这个产品大概是为谁做的，这些人未来有没有「愿意为它长期买单」的可能。如果脑子里完全没有这条路，日常决策就很容易被短期数据牵着走。很多看上去漂亮的增长，不一定是在为未来打基础，有时候只是让你在一条不太适合长期生存的路径上走得更远。
现在再做任何项目，只要心里有一点「它有机会变成一个长期产品」的念头，我都会尽量在比较早的阶段，先粗略想清楚：
● 它大概会服务谁；
● 这些人为什么会愿意长期留下来；
● 他们愿意为什么买单。
这不只是这次经历的感受，其实是这几年所有项目叠加起来给我的提醒。
2. 关于「激励」和「真正的用户」
另一个对我很深的提醒是：激励是一种筛选器。
各种奖励、玩法，在短期内都非常有效，这点我在这个项目以及别的一些项目里都见过。
但它筛出来的，更多是「对激励敏感的人」，而不一定是「对产品本身有强需求的人」。
如果前期一直用这种方式去拉新，很容易导致：
● 数据好看、热度不低；
● 但当你希望产品靠长期价值站住时，发现核心人群其实没有被真正建立起来。
以后再做类似的产品，我会更谨慎地区分：
● 哪些是「为产品本身添砖加瓦」的设计；
● 哪些只是「为了短期刺激」的玩法。
这个反思同样不是在评价哪个项目好或不好，而是提醒自己：
不能只被短期数字牵着走，要时刻记住自己真正希望留下的那一拨人是谁。
3. 方向没想清楚的时候，越努力反而越危险
这段经历里，还有一个挺扎心的感受：
大家都很努力，事情也很多， 但有时候你隐约知道，自己是在用努力填前面没想清楚留下的坑。你越是全力往前冲，就越难停下来问自己一句：
如果照现在这个方向一路做到极致， 那个终点真的是我想要的吗？这个问题不针对任何人，只是对我自己的一种提醒。以后我会更刻意留出一点「按暂停键」的空间，哪怕只是定期问自己这个问题。如果长期答不上来，可能就说明有哪里不太对劲了。
4. 时机本身也是一种成本
这几年回头看，会有一个很强的感觉：
有些窗口期是真的会关上， 关上之后再做同样的事，难度完全不一样。不只是这一次，我接触过的好几个项目都有类似的影子。在某个阶段其实都迎来过一小波关注或讨论度，如果那时能更早地意识到：
● 要不要在那时候认真规划一下下一阶段；
● 要不要借着关注度去争取更多缓冲时间；
后来的剧本可能会不太一样。当然，也未必就一定成功，但至少不是在热度退去之后再来补前面的课。
这件事给我的提醒是：
● 产品有自己的节奏；
● 市场也有它的节奏；
● 有些决定，如果总觉得「以后再说」，其实就是一种隐性成本。
关于「人情」这部分
前面说了很多产品、商业、技术上的东西，但对我个人来说，这段经历还有一块很重要的是「人」。
● 在我第一次被裁、状态很差的时候，是这个项目给了我一个可以重新投入的方向；
● 给了我一个在桌面端、大型 ToC 产品上深度打磨的机会；
● 也让我有机会接触到之前没做到的职责和领域。
不管后来每个人的选择如何，这件事本身我是一直记在心里的。
有时候就是这样。你在别人低谷的时候伸一把手，对那个人来说，意义会很长。
所以，对这段经历，我的情绪是很复杂的：
● 有遗憾，也有不甘心；
● 但也有很多真诚的感谢。
它既不是简单的「成功」或「失败」两个字可以概括的，更像是一次把很多课提前塞给我的密集训练。
对未来的一点想法
短期内，要面对的还是很现实的问题。找下一份工作，解决生活，慢慢让自己从这段紧绷的节奏里抽离出来。
但可以确定的是，以后再谈「做一个可持续的产品」，我的态度会比以前更加谨慎，也会多一点敬畏。
如果你刚好也在经历类似的阶段，或者也在做一个早期项目，希望这些碎碎念能给你一点参考。哪怕只是让你提前避开我走过的一两个坑，也算是这段经历留下的价值之一。
谢谢你看到这里。
看完了？说点什么呢
via 静かな森 (author: Innei)
