思考 on 冯威的博客

万维钢思维100讲的7个概念

Sun, 10 May 2026 12:35:00 +0800

看万维钢《现代思维工具 100 讲》的开篇，发现提到了几个概念。这些概念横跨了决策、心理、物理、统计多个领域，却能解释绝大多数复杂问题的本质。

于是用 ChatGPT 给每个概念配了个图。

1. 古德哈特定律

简单说就是：当一个指标本身变成了目标，它就不再是一个好指标了。

比如公司原本用「打卡率」衡量员工产出，当公司把「全勤」直接当考核目标，大家为了打卡而打卡，反而不会关注实际工作成果，这个指标就失效了。

2. 自我决定理论

这是一个动机心理学理论，核心是：人天生有三种内在心理需求，满足这些需求才能真正维持长期的动机和幸福感：

自主感：能自己掌控做事情的节奏和方式
胜任感：能感受到自己在这件事上能力成长
关联感：能和他人产生联结、获得归属感
用这个理论说，比外在的金钱奖励更能驱动人做好一件事的，是满足这三个内在需求。

3. WOOP

这是一套经过验证的「愿望实现四步法」，是四个单词的缩写：

W（Wish）：明确你想要实现的愿望
O（Outcome）：想象愿望实现后最好的结果是什么
O（Obstacle）：直面你实现愿望路上，会遇到的最核心障碍
P（Plan）：提前制定计划：「如果障碍 X 出现，我就用行动 Y 应对它」
比单纯「幻想成功」更有效，它把乐观想象和务实应对结合在了一起。

4. 自由能

这个词最早来自物理学，现在在人工智能、认知科学里用得越来越多，核心思路是：所有复杂系统（包括人脑、生命）都会主动做一件事——减少「意外」，也就是最小化「自由能」（自由能可以理解成「你想不到的不确定性」）。
换句话说：我们会不断调整自己的行为和认知，让世界尽量符合我们的预期，减少不确定性带来的「惊讶」。现在很多 AI 模型、脑科学理论都用这个思路解释智能的本质。

5. 对称性破缺

原本物理里的概念，现在经常用来解释复杂系统的演化：当系统原本是对称均匀的状态，遇到微小的扰动，平衡就会被打破，分化出不一样的结构。
举个通俗例子：一锅温度均匀的水加热，原本各处都一样，当温度到临界点，一点点随机波动就会让气泡冒出来，原本对称的状态被打破，产生了有序的对流结构。放到社会领域，比如互联网一开始大家都做门户网站，后来某个商家先做了电商，整个行业就分化出了不同赛道，就是对称性破缺。

6. 多臂老虎机

这是决策论里的经典问题，用来解决「探索 vs 利用」的平衡：
你面前有好多台老虎机（多个选项），每台的中奖概率不一样，你不知道哪台概率更高——你是一直选你之前赢过的那台（利用已知经验），还是去试没玩过的老虎机（探索新可能），怎么选才能让总收益最大？
现实里很多选择都是这个问题：找工作，你是一直做你熟悉的工作，还是去试新的领域？谈恋爱，你是继续和现在的人相处，还是去认识新的人？这个框架就是帮你做最优平衡的。

7. 布里尔分数

这是用来衡量「概率预测准确性」的打分方法，简单说：它会算你给出的预测概率和真实结果之间的差距，分数越低，预测越准。
比如你说明天下雨的概率是 80%，结果真下雨了，你的布里尔分数就低；如果说明天下雨概率 10%，结果下雨了，你的分数就高（预测不准）。现在做风险评估、气象预报、AI 预测都会用这个指标来评判预测模型好不好用。

我的知识管理工作流（2026）

Sat, 21 Mar 2026 09:46:00 +0800

明天就是安阳马拉松了，现在在去安阳的火车上，这篇文章是在火车上用手机写的。

这两年，使用过不少的工具，也一直在思考和梳理。明白了一件事：知识管理的核心，不是“我用了多少工具”，而是“信息能不能顺畅地从输入，走到思考，再走到输出”。

目前用的多的是：Get笔记、flomo、Obsidian、墨问笔记。

Get 笔记很适合收集外部内容
flomo 简单、轻巧，它的回顾和洞察我很喜欢
Obsidian 则是我写文章、存资料、践行 PARA 的主阵地
墨问有不错的社区氛围，适合发布文章，交流

不过也遇到些问题。

这些工具都在往“笔记平台”方向生长，于是边界开始重叠，人就容易陷入焦虑：这条内容到底该放哪？会不会记重了？以后还能不能找到？

认真梳理之后，我给自己定下了一个更清晰的原则：不按内容类型分工具，而按“信息来源”和“加工程度”分工具。

换句话说，我不再问“这是读书笔记还是网页摘录”。

而是先问四个问题：

它是外部来的，还是我脑子里冒出来的
它是原材料，还是我的理解？
它会不会被我长期复用？
它是不是已经接近成文？

这四个问题一问，怎么使用工具就比较清晰了。

目前四个工具的角色分别如下：

Get 笔记，负责外部输入与 AI 初加工。它的优势不是“写作”，而是“抓取”。尤其是小红书、抖音、公众号，粘贴链接就可以，非常方便，得到更是能无缝集成。之前写过一篇《[[我为什么喜欢用Get笔记了？]]》

flomo，负责即时想法与轻量发酵。它不是资料库，更像一个思考触发器。官方对它的定位很清楚：帮助用户记录更多想法与灵感，并更好回顾过往记录；它提供每日回顾、主动回顾、相关笔记、AI 洞察等能力。回顾和思考很重要，现在工具越来越方便，更容易收集一大推垃圾，flomo 里更多是主动产出的内容，是比较真实的自己。

Obsidian，负责长期知识资产与深度写作。它依然是我整个系统的底盘。Obsidian 不是一个简单的笔记工具，而是“长期资产库 + 写作工作台”。关键是内容都在本地，安全可靠。

墨问笔记，负责公开表达与社区反馈。官方的表述很直接：墨问并不是传统意义的笔记软件，而是一个创作和分享的工具，让有价值的内容在人与人之间流动。多交流，总能有意想不到的收获。

当四个工具这样重新分工后，很多问题自然就解开了。

比如，日常闪念存哪里？

答案是放 flomo。因为闪念最怕两件事：打开太慢，和记录太重。flomo 的价值就在于它足够轻，能够把一个转瞬即逝的想法先保住。

再比如，读书笔记存哪里？

我后来发现，这个问题根本不能一刀切。摘抄型内容，也就是划线、摘句、摘段，得到电子书直接就同步到了 Get 笔记。

读书过程中的理解、联想、反思，属于我的想法，放在 flomo。

而当一本书的内容被我提炼成一个长期主题，比如“低代码平台的边界”、“企业 AI 落地场景”、“如何高效管理”，它才真正进入 Obsidian，成为可复用的知识资产。

这样一来，我的工作流就不再是机械的“所有内容都必须经过四站”，而是一条有层次的分流系统：

外部内容先进 Get 笔记，使用 Get 笔记的时候也不是存进去就结束了，我会把相同主题的放到一个知识库中，时不时在知识库中有针对性提些问题，也能带来启发。

脑中的想法先进 flomo；值得长期复用的主题资产进入 Obsidian；适合公开传播的内容再去墨问。

真正走完整条链路的，只是少数高价值内容。大部分内容会停在前两层，这是正常的。

结合我这几年的写作习惯，这套工作流还有一个很重要的意义：它把“写文章”从一个临时动作，变成了一个自然生长的过程。

我平时会持续关注 AI、架构、产品、管理、跑步训练这些主题。以前常见的问题是：收藏了很多，想法也有，但真正写成文章时，总感觉素材散、观点浅、结构临时拼。

现在则不同，Get 笔记负责把外部世界的信息收集进来，flomo 负责留下那些真正打动我的判断，Obsidian 则负责把分散的想法组织成专题。等到某个主题在 flomo 里已经反复出现、相互连接时，我再进入 Obsidian 去写，文章就不再是“硬挤出来的”，而更像“顺势长出来的”。

所以，2026 年我的知识管理工作流，已经不再追求“全都要”，也不再追求“记得越多越好”。

工具没有减少我的思考，工具只是让我更容易看见：哪些信息只是路过，哪些内容值得沉淀，哪些想法值得反复打磨。

最后，希望明天安阳能顺利跑进 330 ！

2025 年终总结

Tue, 17 Feb 2026 02:16:00 +0800

岁月匆匆，华章日新，今年春节比较晚，现在 26 年都已经过了快 2 个月了。还是来对 2025 年做下总结吧。

整体感觉就是快，时间过得很快，AI 的发展速度也非常快。

怎么应对 AI 时代

从年初的 DeepSeek R1 到现在的 Agent Skills，几乎隔几天就会有新的模型、工具、应用出现。最近爆火的 Seedance 2.0 也在豆包移动端上线了。

我在手机上打开豆包，却不知道要做什么视频，因为我没有任何视频制作的经验。

所以说 AI 工具是在放大专业者的能力，而对菜鸟来说，只能是找点乐子的玩具。

[[AI 时代其实对人的要求更高了]]

放假前，在公司组织了一场 AI 技术应用分享。几乎所有人都用过 AI 相关的工具，但使用程度各有不同，对新技术和工具的了解和使用只是少部分人。很多人还停留在让 AI 协助排错的阶段。

AI 时代，持续学习显得尤为重要，持续关注、持续实践。

近一年也写了不少跟 AI 相关的文章：

[[理性看待 Manus]]
[[12个问题深入理解DeepSeek（含开源周内容）]]
[[在Windsurf中使用李继刚提示词]]
[[MCP 和 Function Calling：概念]]
[[MCP 和 Function Calling：示例]]
[[生成式AI 在 B端软件中实践的思考]]
[[A2A 介绍：概念篇]]
[[如何构建多智能体系统？]]
[[AI 时代，低代码该如何演进？]]
[[Agent Skills 全景指南：从概念机制到实战开发]]

成长

个人成长对我而言，是信息的获取到内化的闭环：输入阶段保持开放，消化阶段保持批判，内化阶段保持实践。

信息的获取源有：公众号、小红书、小报童、读库、得到、X、语鲸、Folo 。

语鲸和 Folo 是聚合工具，可以快速浏览，如果需要看原文的讨论，也能方便跳转过去。Get 笔记是最近比较喜欢使用的一款工具，支持公众号、抖音、小红书、B 站、小宇宙的链接分析。他们自己家的得到 APP 更是可以无缝同步。

[[我为什么喜欢用Get笔记了？]]

输出工具还是使用 Obsidian，而且用的更深入了，最近也准备写一篇 Obsidian 常用插件的使用。在没有找到合适插件的时候，也可以借助 AI 的能力自己写一个插件。

[[插件开发：实现Obsidian同步到墨问笔记]]
[[插件开发：实现 Obsidian 同步到 hexo]]

在 [[2024 年终总结]] 中我提到在 25 年要慢下来，注重消化。我自认为做的还是不错的。比如说我在看一些知识类的视频或书籍时，会选择在电脑端开着笔记工具去看，边看边记录，避免走马观花，觉得自己会了。

2026 年 1 月看了马伯庸和脱不花的长谈，学到了一个习惯：写日记。

这种记录日记的方式，只记录事实，不发表评论，希望 2026 年可以坚持下去，等到年末回顾的时候应该挺有意思的。

跑步

2025 年比赛历程：

3 月，仙桃半马跑到了 133 ，得益于赛道的平坦和天气的给力，425 的平均配速，平时可是连 10 公里都跑不到
4 月，云丘山越野赛 50 公里组别，虽然跑的慢，还是安全完赛
12 月，杭州隆 6 越野赛，42 公里组别，因为赶车而退赛

[[天气和赛道的加持，仙桃半马 PB 9分钟]]

警惕效率的陷阱

Wed, 26 Nov 2025 15:49:00 +0800

企业谈降本增效，个人也是一样，不断尝试各类效率工具。即便是教育小孩，也是希望用最少的焦虑、最短的时间，换来好的结果。总之，就是要高效。

现在层出不穷的大模型和琳琅满目的 AI 工具，其目的也是为了效率的最大化。

关注效率的同时，也需要警惕一些效率陷阱。

忙碌替代产出。

常见现象是为了找一个好用的笔记工具，可以花大量的时间查资料、看评测。但笔记却没有写多少。同类的事情还有囤积电子书、各类资料。主打一个收藏了即看了的效果。

看似一直在忙碌，却没有产出。

就拿记录这个事情来说吧，家里领导就做的很好，先找个工具用着，过程中发现有些需求没有满足，再去寻找新的工具。

目的是产出内容，工具只是辅助。

把指标当目标。

说到指标，就会想到 KPI，很多公司都有 KPI 考核，比如对程序员会有工作量、Bug 量、是否延期等指标。

如果指标不是为了更好实现目标，而是将指标当成了目标，那么这个 KPI 就是失败的。

英国经济学家查尔斯·古德哈特提出了一个古德哈特定律：“当一个指标被设定为目标时，它就不再是一个好的指标。”

比如，如果对程序员只考核工作量，程序员把工作量当成自己的目标，那就会无视代码质量、无视项目进度，只要自己工作量达标即可。

优先级错乱。

四象限法将事情分为：重要紧急、重要不紧急、不重要紧急、不重要不紧急四类。目的就是让我们做事前想想优先级，这样效率更高。

有个项目经理每天应付客户的各种事情，非常忙。负责的项目从测试发布到生产需要用到同步工具，使用过程中，发现同步工具存在很多的问题，这个项目经理就手动进行发布，要多花几倍的时间。

后来同步工具修好了，需要在客户的测试环境中验证，项目经理觉得自己很忙，没时间做这个事情，依然手动同步，耗费大量时间。

有时候忙，并不是真的忙。

忽略协作成本。

在一个组织里要做成一件事，必然会涉及各个部门的协作。如果部门之间各自为政，沟通和协作不顺畅，就会存在 “部门墙”。

这种沟通和协作成本是隐性的，不容易被看见，但最终会体现到结果上。

有一个竖井效应说的就是这个事：

竖井效应指的是公司内的各个职能团队各自为政，每个团队都很高效，但从全局的视角去看却不一定是高效的。

埋头苦干，缺少思考。

当项目的交付时间提前了、或遇到困难了，第一反应是：我们要更努力了、要抓紧时间了、需要加班加点了，而不是停下来分析问题的根源、重新评估方法和策略是否有效。

这就是用战术上的勤奋，掩盖战略上的懒惰。就像在迷宫里找出口，选择了拼命快跑，而不是想办法找到地图。

其实停下来分析、思考，有些事情是可以延后处理，甚至是不处理。

AI 时代，低代码该如何演进？

Tue, 04 Nov 2025 14:49:45 +0800

在数字化转型的浪潮中，低代码平台与人工智能（AI）的结合正成为企业软件发展的关键趋势。

低代码平台以其快速开发、交付等特性，正在改变企业应用的开发方式，而 AI 把企业从 “流程数字化” 推进到 “决策智能化” 。这两者一定可以碰撞出不少的火花。

本文探讨低代码与 AI 融合的方式。

低代码和 AI 有两种方式可以结合

方式一：在低代码平台中使用 AI，把 AI 能力沉淀到平台内部，提升用户体验和效率。
方式二：在 AI 中使用低代码，将平台的核心能力封装成细颗粒度工具，成为大模型与智能体的“手脚”。

这两种方式并非二选一，而是相互增强，根据客户的业务场景进行取舍和选择。

方式一：低代码中使用 AI

低代码的优势是可以快速交付项目，结合 AI ，可以让构建出来的业务系统具备 AI 能力，在低代码平台中 AI 能力了可以通过组件或插件的形式存在。

下面列举几种常见的场景。

企业级智能问答

RAG 现在在企业中使用已经非常成熟了，RAG 中有一个关键点是将内容进行向量化，供用户提问时使用。

低代码平台中天然就有很多的数据：

低代码平台可以搭建各种业务功能，随着用户的使用，业务数据就会累加，可以在平台中根据配置选择性将业务数据纳入到知识问答的范围。
低代码平台中的文件列表，在用户上传文件时，可以对文档内容进行读取和向量化。
在使用低代码平台构建应用时，数据库表的创建是根据平台中的数据模型进行转换的，数据模型就是一份数据库表的元数据。

至于前端的问答对话框的呈现就比较灵活了，可以是单独一个页面、可以放到首页，也可以放到某个功能模块中，针对具体的业务进行提问。

审批流 AI 节点

企业将线下的审批搬到线上，为的就是能提高效率。某些审批环节，如果能使用 AI 加持，就能更进一步。

比如：员工报销流程，财务会对上传的发票和报销金额进行审核，当一个报销单的发票比较多时，人工核对会非常麻烦。

结合 AI ，可以在低代码平台的流程引擎中提供一个 AI 辅助审批节点，发起人提交后，将票据传给 AI ，AI 进行金额的识别和汇总，并根据规则配置和报销金额进行比对，发现问题直接驳回给发起人。

报表多轮对话

我们现在给企业客户开发软件的过程中，根据客户的业务需求，会提供很多的报表，有些是专业的报表工具、有些通过视图关联多表查询出结果展示。

但这些随着需求的确定，功能就固化下来了。客户在使用的过程中只能通过条件进行筛选。

结合 AI ，用户可以在现有报表数据的基础之上进行二次提问，结果以文字、表格、图表的方式提供，让报表变得更加灵活。

文档解析

企业中有很多不同类型的文档和单据，比如：合同、发票等。可以在低代码平台中添加文档识别组件。

利用文档识别组件，可以构建一个专门用来管理票据的功能。
合同管理中在文档识别组件中上传，识别合同基本信息，一键将识别的信息填写到表单中。

除了基本信息，甚至可自动识别文档中的关键节点，如合同中的付款信息与时间等，并同步至低代码构建的事务跟踪系统，显著减少人工查阅与录入的工作量。

方式二：在 AI 中使用低代码平台

AI 只有具备了生产能力，才能真正帮到我们。怎么才能具备生产能力呢？就是使用工具。

我们和大模型进行对话，大模型理解了我们的意图，还能调用工具去进行实现，才是有用的。低代码平台中有各类引擎（表单、规则、视图、流程等），这些引擎的能力可以进行拆解和重组，以 MCP 工具的形式提供给大模型。

场景一

用户指令：创建一个员工信息管理应用，包含姓名、工号、部门和入职日期的表单，以及一个可以搜索和分页的表格。

工具调用：大模型理解意图后，调用低代码平台的 API，自动创建数据模型、生成对应的表单页面和列表页面，并配置好基本的数据绑定。

场景二

用户指令：任务管理中创建任务后，给任务负责人发送一个企业微信通知。

工具调用：大模型理解意图后，分析需要调用的工具集，先调用低代码平台的 API，创建一个用于发企业微信消息的业务流。然后调用 API 将任务创建后的事件和业务流进行绑定。

场景三

用户指令：检查一下我们所有低代码应用的运行健康状况。

工具调用：大模型理解意图后，调用平台的监控API，获取应用错误日志、性能指标（如响应时间）、资源使用情况等，并生成摘要报告。

最后

网上都说，AI 的到来最终会转向无代码，不过从目前来看，让 AI 自己去实现一个复杂系统，还是比较困难，特别是多轮对话后，幻觉比较明显。

低代码平台天生就是构建应用的利器，而且是有规则的，这个规则相比较编程语言，范围更小，更容易被 AI 所理解。

所以，在 AI 无代码变成这条路上，低代码平台如果能转变为底层支撑的工具，将会继续存在。

未来，随着模型能力的持续进化与平台工具的日益精进，人机协同的开发新模式将成为企业数字化转型的核心竞争力。

信创浪潮下的.NET困境与技术转型思考

Mon, 16 Dec 2024 16:23:00 +0800

开始之前我想先介绍下什么是.NET、什么是信创？

什么是 .NET？

我们现在说 .NET 通常指 .NET Core 之后的版本。.NET Core 是跨平台的开源框架，不仅可以运行在 Windows，还支持 Linux 和 macOS。在 .NET Core 3.1 之后发布的 .NET 5 又做了大统一，名称中也去掉 Core 了），目前最新的版本为 .NET9 。

.NET 有以下几个特点：

1、采用最开放的 MIT/Apache 2 协议开源，具备中立性。

2、归属中立的第三方组织 .NET 基金会管理，不属于任何商业公司，进一步增强了其独立性和开放性。

3、完全支持 ARM 32/64 架构，适配国内主流的 ARM 架构芯片，如鲲鹏、飞腾等。

什么是信创？

信创，即信息技术应用创新产业，其核心目标是实现信息技术领域的自主可控，以保障国家信息安全。国资委 2022 年 79 号文件主要指示如下：

核心内容：要求在 5 年内国企全部完成信创替换。

实施步骤:

1、2022 年 11 月底，完成信创改造方案规划并报送国资委；

2、2023 年 1 月起，每季度报送信息化系统信创改造的最新进度；

3、2027 年底，全部央国企必须完成信息化系统的信创改造工作。

替换要求：

1、全面替换：OA、门户、邮箱、纪检、党群、档案、经营管理。

2、应替就替：战略决策、ERP、风控管理、CRM 管理系统。

3、能替就替：生产制造、研发系统。

为什么要发展信创？

1、保障国家信息安全：随着信息技术的快速发展，网络安全风险日益增加，发展信创有助于提升国家信息安全水平。

2、实现自主可控：历史上，中国在信息技术领域长期依赖国外技术，发展信创可以推动国内信息技术产业的发展，减少对外部技术的依赖。

4、应对国际竞争：在全球信息技术产业竞争加剧的背景下，发展信创产业有助于提升国家的国际竞争力。

4、促进数字化转型：信创产业的发展有利于国内企业更安全地完成数字化转型。

.NET 支持信创吗？

毫无疑问，从技术上来说，.NET 是支持信创的。

但是，这没有用，客户不听解释。

随着 27 年的临近，企业的信创进程在加快。最近见了不少客户，不管是否了解技术，都谈 .NET 色变，有的更是将 .NET 纳入了黑名单。有客户原话是：

我也知道 .NET 是支持信创的，但集团下了文，不让用，我们也没有办法。

幸好我们产品比较开放，很早就是多技术栈并行的。不过也很无奈，需要全面进行技术栈迁移了。

转型

说到无奈，是因为要做出改变，就要离开舒适区了。但仔细想想，舒适区待久了很难让人进步。这次的转型也许会成为再上一层楼的一个契机。转型分为两个层面：技术和业务。

技术

1、代码块节点使用到的 nodejs、python 还是继续保留。

2、剩余的 .NET 部分全部转换为 Java。

3、转换后的 Java 程序需要和原来的 Java 代码一起通盘考虑，架构上需要重新考虑和规划。

4、合理梳理业务链路、优化缓存的使用，进一步提升性能、稳定性和扩展性。

业务

我们的产品为低代码类型的产品，目的是能快速高效地为客户落地业务。现在随着 AI 技术的发展，我们产品也需要做出相应的变化。

代码写的好，就可以不写技术文档了吗？

Wed, 23 Oct 2024 16:08:00 +0800

在软件开发中，代码与文档的关系是一个经常被讨论的话题，最近在一个技术群里也针对这个话题展开了讨论，大家各抒己见，以下是群中的一些主要观点，希望对你有所启发。

观点一、代码无法替代文档，文档是必需的

在项目的初期阶段，文档对于需求分析和设计至关重要，它帮助团队理解整体目标和约束。而在实现和维护阶段，代码是核心内容，但文档依然不可或缺，用来补充背景信息、重点逻辑等，确保团队的有效协作。

团队成员水平参差不齐：在大型团队中，成员的编码水平和理解能力不同，仅靠代码无法确保所有人都理解项目的全部细节。文档可以为经验不足的成员提供必要的指导，帮助他们更快地融入项目。
代码难以表达设计思路和决策过程：代码是最终实现的结果，但难以完整传达开发者的思考过程、约束条件，以及为何选择某种实现方式。这些背景信息对于后续的维护和迭代非常重要。
知识传承的需要：代码会随着时间和技术的演进而过时（指的是有些历史代码架构、实现可能都不是最优的，但一直在稳定运行，没就没有去进行重构），但文档能够记录项目的核心理念和设计思路，帮助新成员快速上手，减少摸索的时间成本。
写好代码的成本高于写文档：高质量代码的编写需要丰富的经验和时间，而编写简洁而清晰的文档相对容易，可以迅速传达重要的信息。
文档面向多种读者：代码主要面向开发者，而文档可以针对不同的受众，如非技术人员和管理层，帮助他们理解项目的整体状况和业务逻辑。
避免误解和知识诅咒：开发者通常认为自己的代码已经足够清晰，但对其他人来说可能并非如此。文档可以填补理解上的差距，降低沟通成本。

观点二、代码和文档是互补的，应该同时重视

在小型团队中，沟通相对简单，文档的需求可能较少，更多依赖于自解释代码和口头沟通。而在大型团队中，成员众多且角色多样，文档的重要性显著提高，有助于团队成员理解项目背景、业务逻辑和设计决策，降低沟通成本。

自解释代码减少了部分文档需求：如果代码命名规范且逻辑清晰，部分重复性的文档可以省略，这符合 DRY（Don’t Repeat Yourself）原则。
代码无法替代所有文档：即便代码写得再好，也无法描述项目的背景、业务逻辑、设计决策等信息，这些内容往往需要在文档中进行详细说明。
团队协作需要平衡：团队应通过讨论来确定文档的必要性，确保每个成员都参与到文档的维护中，促进知识的共享和流动。
文档需要更新：过度或形式化的文档可能流于形式，反而成为负担。因此，需要合理的文档管理和及时更新，以确保其质量和实用性。
代码需要达意： 即便有很清晰的文档，开发人员最终还是需要去阅读和修改代码，所以代码本身的质量也非常重要。

观点三：过度依赖代码或文档都会带来问题，关键在于平衡

在敏捷开发中，找到代码与文档的平衡尤为重要。例如，有一个团队在开发过程中采用了「轻文档化」策略，针对关键模块和复杂业务逻辑编写简要的设计文档，而对于简单的实现则依赖于清晰的代码注释和团队协作。这种方式既保证了开发效率，又确保了文档的实用性和及时性。

过分强调代码会忽略知识传递：没有文档的项目在团队人员变动时可能会面临严重的知识流失问题，从而影响项目的长期维护和发展。
过度依赖文档可能导致低效：如果文档过于冗长或没有及时更新，开发者最终还是不得不查阅代码，这无疑增加了时间成本。
培养文档使用文化：如果没有人阅读文档，开发者也就缺乏编写的动力。因此，团队需要培养阅读和利用文档的文化，使文档成为项目不可或缺的一部分。

观点四：澄清对「代码即文档」的误解

代码清晰就不需要文档：某团队在开发初期认为只要代码写得足够清晰，就不需要额外的文档，导致后期新成员加入时对业务逻辑缺乏理解，不得不花费大量时间追溯代码背后的背景信息。
敏捷开发不需要文档：有些团队误解了敏捷开发的原则，认为敏捷就是不写文档，结果在项目需求变更时，由于缺乏文档记录，变更管理变得困难，最终导致项目进度延误。
注释等同于文档：某项目的开发者认为在代码中添加详细的注释就可以替代文档，但注释通常只针对具体的实现，而无法传达整体的设计思路和决策过程，导致项目在维护过程中，尤其是面对复杂业务逻辑时，出现困难。
敏捷宣言的误读：敏捷开发提倡「可工作的软件胜过面面俱到的文档」，但这并不意味着不写文档，更不代表代码可以完全替代文档。
「代码即文档」并非全覆盖：这一观点强调代码的可读性，但并不意味着代码能够表达所有类型的信息，特别是那些代码无法承载的项目背景和业务逻辑。
避免走极端：认为写好代码就不需要任何文档是一种极端做法，不利于项目的长期发展和维护。

我的观点

代码除了让机器执行出结果，还需要人去阅读、修改、维护，所以每个开发人员需要持续提升自己的技能，从变量方法的命名到类之间的结构是清晰的、易读、可维护的。
如果代码质量很高，变量、方法上面的一些废话注释不是必须的，没有这些，代码反倒看着更简洁，但整个项目的整体架构、核心业务的逻辑、算法等还是需要沉淀到文档中，并且随着代码的迭代演进，文档也需要同步更新。
我不认为一个代码写的逻辑混乱的人，可以写出很清晰的文档。所以还是要先从代码入手，让每个人都能写出好到代码，再强调特定文档的重要性。

希望对您有所帮助！

对提升项目效率的一点思考

Tue, 20 Aug 2024 08:17:14 +0800

在一个软件企业中，项目实施效率非常重要，它关乎企业的竞争力，影响项目交付的速度和质量，关系到企业的盈利能力，甚至决定着企业的生死。

认真深入做一件事，从跑步开始

Wed, 10 Jan 2024 17:09:43 +0800

去年的 1月 22 号是大年初一，我写了一篇《2023 关键词：做减法》，回顾这一年，做的不算太好，但是朝着这个方向在走，在 2024，我想在做减法的基础上，再多给自己一个要求，就是要认真深入地去做一件事。

为什么会有这个想法呢？还得从跑步说起。

由 ChatGPT 带来的对低代码产品的思考

Thu, 13 Apr 2023 11:42:00 +0800

在之前的文章中多次提到我们在开发一款低代码平台，主要面向 ToB 企业，帮助企业完善信息化建设，给企业的数字化转型贡献一份力量。

技术人如何打造个人品牌？

Mon, 20 Jun 2022 08:20:20 +0800

对技术人来讲，个人品牌非常重要，个人品牌的建立是自我营销的一种方式，也是提升个人价值的一种方式。

那什么是品牌呢？一篇文章、一个视频火了，这个不算是品牌，如果提及某个领域，大家能想到你，这就是品牌了。

当谈研发效能时，在谈些什么？

Wed, 01 Jun 2022 00:00:00 +0800

最近翻了下之前写的公众号文章，发现研发效能相关的就有三篇：

怎样提高开发效率
关于增效，需要做好这两点
再谈研发效率提升

从工具使用、业务的理解、团队的沟通协作到流程、组织、分享等内容，我能想到的大部分有关研发效能的点都有涉及到。

做个成年人

Mon, 23 May 2022 00:00:00 +0800

奈飞内部曾经流传出一份企业文化的 PPT ，被誉为硅谷最重要的文件，后来这份 PPT 经过重新整合出版，就是《奈飞文化手册》。

在《奈飞文化手册》中介绍的第一个文化准则就是：我们只招收成年人。

这里所说的成年人不是年龄上的成年，而是心智上的。所谓成年人，就是有责任，有担当，能控制好情绪。

结构化思维

Tue, 10 May 2022 08:08:42 +0800

在说结构化思维之前，先看下面两个小案例：

如何提升写作能力？

Thu, 05 May 2022 08:06:18 +0800

尽管我在公众号已经发了 130 多篇原创文章，而且在写公众号之前，还写了十来年的博客，可我依然觉得我不会写作。

之前写的大部分都是技术文章或一些总结，能把一个技术点讲清楚，让不懂的人有所收获，我认为就很好了，就算对他人没有帮助，也能作为自己的一个备忘录。