列表请求应该放在哪当用户登陆系统后，有一个最直接的需求：“作为一个用户，我可以获取到所有的应用的任务列表，以此快速查询到我想要的任务数据。” 大概功能入下图所示。现在，我们基于用户故事更新一下业务模型
123456789101112131415classDiagram class User { +id: int +name: string +email: string +workspace: Workspace } class Workspace { +id: int } class Task { +id: int } User "1" -- "*" Workspace User "1" -- "*" Task
我们可以看到，用户和任务之间也是是一对多的关系，我们的现实场景下，代码设计大概如下。如果移动端用户有同样的需求， ...
大家好，我叫钟杰，我所在的公司是做低代码的，低代码行业基本都在尝试引入 AI 智能体，通过训练存量客户所搭建的应用数据，来帮助后续客户快速上手产品。大概流程就是：提出类似于“我要搭建一个生鲜市场的出入库管理系统”，之后系统会创建好一个相对完整的表单应用。然后客户在半成品上基于自己的需求，去进行更新。
在 ai 工具出现以前，客户搭建自己的应用是通过内置模板 + 帮助文档，在和公司客户成功团队的帮助下，基于自己的需求，搭建匹配业务的应用，这也是大部分 SAAS 和 低代码工具的运营模式。企业希望通过 AI 工具的引入，借此降低公司客户成功团队和客户之间的沟通时间于成本。从而服务于更多的客户来赚取更多的利润。也许是因为近两年对于各类 AI 的营销，都是以降本增效为卖点，再加上公司的盈利能力在不断下降，公司将 AI 看作了提升人效比的银弹，殊不知人效比的核心在于人（团队）的打造，而不是简单的将 AI 工具，粗暴地代替工作流程的某一个环节。
引入工具但不引入标准这个问题其实在 ai 工具出现以前，就已经大量存在了。比如
“死文档式”记录：引入敏捷开发的站会、看板，却不构造通用语言，依旧以开 ...
大家好，我叫钟杰，是个做了 4 年的前端工程师，我所在的公司是做低代码的，低代码行业基本都在尝试引入 AI 智能体，通过训练存量客户所搭建的应用数据，来帮助后续客户快速上手产品。大概流程就是：提出类似于“我要搭建一个生鲜市场的出入库管理系统”，之后系统会创建好一个相对完整的表单应用。然后客户在半成品上基于自己的需求，去进行调整。
在 ai 工具出现以前，客户搭建自己的应用是通过内置模板 + 帮助文档，在和公司客户成功团队的帮助下，基于自己的需求，搭建匹配业务的应用，这也是大部分 SAAS 和 低代码工具的运营模式。企业希望通过 AI 工具的引入，借此降低公司客户成功团队和客户之间的沟通时间于成本。从而服务于更多的客户来赚取更多的利润。也许是因为近两年对于各类 AI 的营销，都是以降本增效为卖点，再加上公司的盈利能力在不断下降，公司将 AI 看作了提升人效比的银弹，企图通过粗暴地替代某一个环节，来降低整体的成本。
引入工具但不引入标准对于工具的盲目崇拜，其实在 ai 工具出现以前，就已经大量存在了。比如
“死文档式”记录：引入敏捷开发的站会、看板，却不构造通用语言，依旧以开发 90% ...
大家好，我叫钟杰，是个做了 4 年的前端工程师，我所在的公司是做低代码的，低代码行业基本都在尝试引入 AI 智能体，通过训练存量客户所搭建的应用数据，来帮助后续客户快速上手产品。大概流程就是：提出类似于“我要搭建一个生鲜市场的出入库管理系统”，之后系统会创建好一个相对完整的表单应用。然后客户在半成品上基于自己的需求，去进行调整。
在 ai 工具出现以前，客户搭建自己的应用是通过内置模板 + 帮助文档，在和公司客户成功团队的帮助下，基于自己的需求，搭建匹配业务的应用，这也是大部分 SAAS 和 低代码工具的运营模式。企业希望通过 AI 工具的引入，借此降低公司客户成功团队和客户之间的沟通时间于成本。从而服务于更多的客户来赚取更多的利润。也许是因为近两年对于各类 AI 的营销，都是以降本增效为卖点，再加上公司的盈利能力在不断下降，公司将 AI 看作了提升人效比的银弹，企图通过粗暴地替代某一个环节，来降低整体的成本。
引入工具但不引入标准对于工具的盲目崇拜，其实在 ai 工具出现以前，就已经大量存在了。比如
“死文档式”记录：引入敏捷开发的站会、看板，却不构造通用语言，依旧以开发 90% ...
大家好，我是在前端市场摸爬滚打近 4 年的前端开发。这段时间，由于企业盈利能力下降，我也尝试跳出开发角色，观察产研的成本消耗，大概总结为以下几点：
“死文档式”记录：即所有的业务知识记录在类似于语雀的外部文档中，但是并没有持续地进行更新（或者是业务发生变化后，就新开一个文件）。随着人员的流动，我们很难追溯已有的逻辑。最后的沟通就变成了“按照线上来”，“线上咋样，不知道啊”。所谓的拆解，工时预估，也不再具有参考意义。
“埋雷式”开发
：做到一半了，才发现原来这段代码被另一个业务引用了。那怎么办呢，if-else 大法，或者直接 cv 大法。反正“代码和人能跑一个就行”
只磨刀不砍柴：质量监测工具(SonarQube，test covery，sentry) 的根本作用在于减少人工发现代码问题的成本，但是发现问题后呢？”测试覆盖率不足是否有制定要求“，“代码重构前是否有覆盖安全网”。问题越积越多，解决越来越少
这些问题，我将其称为四驱车式开发，即只有横冲直撞碰到问题后，才去扭转方向，原有的问题依旧存在，随着累积问题越来越多，四驱车只能在一个名为“大泥球”的遗留系统内胡乱碰撞。这些国内 9 ...
在职场中，每个人都想向上走，每个人都有自己模仿的目标。为了在职业的阶梯上步步高升，我们和上一级的人的差异究竟是什么呢？是这个人工作年限比我长，还是这个人平时开会比较多。是不是代码量累积到一定程度，就自然达到这个位置呢？很显然不是。
真正的原因在于，developer 看到的是任务，engineer 看到的是整个系统，manager 看到的是企业协作流。《穷查理宝典》中，讲到绝大多数人都妄图用一套思维模式，去解决世间大部分问题。就好像 developer 相信技术可以改变世界，时不时花大力气去解决一个可能并不是问题的问题。正如《像火箭科学家一样思考：将不可能变为可能》提到，随着时间的增长，我们会受到既定经验的约束，日复一日，年复一年做同样的事，与同样的人打交道，保持同样的产品线。作为一个 developer，是不是过于依赖过去的工作流程和学习方法。在既定的流程上呆久了，丧失了跳出自己思维的能力。
那么从这个角度来说，要提升的方向就很明显了。我们要进入比 developer 更大的上下文，走出庇佑自己多年的大树，进入未知的森林中。不负责项目，也可以去了解系统本身；不是产品经理，平时看看产品 ...
知识管理
未读背景众所周知，博客的部署、运营、维护和备案并不简单，现在主流的博客方式一种是使用如 hexo 和 hugo 静态网站生成器把 markdown 文件转化为浏览器能识别的 Html 文件。这种通常都是在 vscode 中进行文稿的编写，但是 vscode 侧重于编写代码和复杂程度不高的文档，而且在 vscode 缺少了一种连接文档与文档关系的“双链”功能。另一种是使用飞书、语雀、notion 等在线富文本编辑器，这种方式数据是存储在线上的，且没有友好的本地备份方式，对于我这种数据敏感型用户，这类工具实在不友好。这样下来，我能选择的工具就只有 obsidian 了。obsidian 有以下优点：
数据完全地本地化，掌控在自己手里的感觉是最棒的
丰富的插件生态，只要不是文章里必须有视频这种大文件，基本都能找到解决方案。
关系图谱与双链支持，这 2 个功能，能够帮助构建知识与知识之间的联系，打造属于自己的知识体系。
要回答这个问题，首先我们要明白，我们平时做笔记是为了什么。
笔记总的来说有 2 种作用：第一种是编码作用：也就是我们平时在学习新知识的时候，拿着笔在纸上写写画画，往往比干看有效的多。第二种是存储作用：想象一下，一个需要花费 10 分钟阅读的文章，当我们重复学习的时候，在已有笔记的帮助下有目的的去回顾对应的内容，肯定能比重新阅读这篇文章更快地回忆所学。
以上 2 种笔记作用结合起来，也就是我们平时所做的个人知识管理。
我们回到一开始的问题，当下的 AI 能否解决我们的需求呢？显然还是不行的，学习的本质是靠不断重复打造长时记忆。在每一次的重复中，我们都在对已有的知识进行更加精细的加工，这些不断加工的内容，又会和已有的知识不断地联合起来。最终我们读一本书会经历 2 个阶段：
把书读薄：根据 2/8 原则，抽象精简出最重要，真正触动自己的地方。
把书读厚：把新学到的知识和已有的知识联动起来。比如“眼花缭乱”的原因是脑科学中“人看到的内容并不像照片一样所见即所得，而是大脑不断的在渲染眼球捕获到信息，当信息过多时，大脑就会过载”。反过来说，有意识地控制眼球，有助于防止胡思乱想，所以 ...
