效率 on 冯威的博客

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

Mon, 02 Feb 2026 10:00:00 +0800

最近项目里发生了一件特别有意思的事，非常值得复盘。

项目经理给一位开发同学布置了一个功能模块，按理说难度不大。考虑到现在 AI 编程工具这么强，项目经理估计很快就能搞定。结果呢？这位同学整整搞了一天还没弄完。

项目经理很纳闷，问他：“你没用 AI 协助吗？”

开发同学一脸苦笑：“用了啊。就是因为用了 AI，我才搞到现在。”

原来，他把需求扔给 AI 后，AI 产出了代码和运行结果，这位开发同学又花了大量时间逐项核对。

最后算下来，效率反倒不如纯手写。

这位同事的问题，在于他依然以“写代码”的思维使用 AI，而不是以“验收结果”的思维。

当我们自己写代码时，脑子里是有完整逻辑的，写出来的每一行都心里有数。但当 AI 生成代码时，对我们来说是一个“黑盒”。

我们需要从执行者转变为架构师视角。

在上面这个场景里，我们如果转变思路，把自己当成一个架构师，把 AI 当成负责编码的程序员。会发生什么？

试想一下，如果你给一位开发派活，你会只说一句“帮我做个登录功能”吗？肯定不会。因为你知道一句话需求会导致最后做出来的东西可能完全偏离了方向。

那要怎么做呢？

我们会写详细的规格说明书和接口文档，明确交付标准。然后将这些告诉开发，要按照这些要求来写代码。

对 AI 也是一样。

结合这个案例，我认为要提高 AI 协作效率，必须做好以下几点：

1、边界

告诉 AI 目标是什么、哪些要做、哪些不能做。只有当 AI 清楚知道“要做什么”并且“什么不能做”时，才能正确执行任务。

2、任务拆解

不要把一个大需求直接丢给 AI。正确的做法是拆解。把大任务拆成一个个独立的、可验证的小的任务。

任务越小，AI 犯错概率越低，检查的成本也越低。

3、反馈

当 AI 给出的结果有问题时，我们要能快速识别，并及时提供反馈。

如何才能快速识别？

这就需要我们掌握架构知识和底层原理，所以说 AI 帮我们提升效率的同时，我们自己的能力也需要提升才能更高效地配合。

好的反馈能让 AI 一次性修正错误，避免陷入无效的反复沟通。这不仅省钱（省 Token），还能让 AI 尽可能少地产生幻觉。

4、上下文

AI 和人一样，需要上下文。

一个新人进入团队，需要熟悉工作环境、使用的工具、项目的情况、文档、代码库等，这些就是上下文；上下文越充分，就越容易上手。

5、目标

我们做项目，客户的真实诉求是什么？挖得越深，就会越顺利，可以在后期避免很多不必要的返工。

指挥 AI 干活，也需要让 AI 知道我们的目标和意图是什么，只有这样，产出才不会有偏差，有时甚至有惊喜。

6、验收标准

把任务指派给 AI，必须让 AI 知道什么叫“做完了”。

不要小看这个“做完了”，很多时候，项目经理和开发的理解都不一样，开发认为代码写完就算是做完了，项目经理要对最终的业务负责，考虑的更全面。

首先我们要明确这个标准，再告诉 AI。否则，如果我们自己都不清楚验收标准，AI 就不可能产出符合要求的结果。

忙碌的陷阱

Mon, 23 Sep 2024 08:35:29 +0800

在一个公司中，当所有人都很「忙碌」时，常常被视为高效和生产力的象征，但如果项目还是不能按时上线、客户投诉比较多，满意度差，就需要思考：这种忙碌是真的高效吗？我们是不是陷入了忙碌的陷阱了呢？

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

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

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

Logseq：使用一年的感受

Tue, 27 Jun 2023 10:45:05 +0800

去年 6 月 20 号写了一篇《Obsidian 初体验》，也就是从那时起，开始使用 Obsidian，随后不久，知道了 Logseq 这款软件，就同时使用 Obsidian 和 Logseq 。

代码提交那点事

Mon, 13 Feb 2023 09:46:06 +0800

现在，代码的版本管理大多都在使用 git，常用的一些代码托管平台有：Github、码云、Gitlab 等，不管用的哪个平台，我们经常会做提交代码的操作，但很容易忽视 commit message 的写法。

太卷了，Obsidian 和 Logseq 纷纷推出白板功能

Fri, 06 Jan 2023 21:31:53 +0800

白板应用相信大家都不陌生，随便一列举就有不少：

Excalidraw ：https://excalidraw.com/
ProcessOn 出的小画桌：https://www.xiaohuazhuo.com/
heptabase : https://heptabase.com/
苹果的无边记，要求版本：iOS 16.2，iPadOS 16.2，以及 macOS Ventura 13.0
https://okso.app/

白板有一个共同的特点就是无边，上下左右可以无限扩展，没有边际，其他的则各有侧重点，有的支持良好的协作、有的支持多种白板元素，从功能上来说，我认为可以分为两类：

ChatGPT 之后，再玩玩 Stable-Diffusion

Mon, 26 Dec 2022 08:53:38 +0800

前些天体验的 ChatGPT 主要用来进行文本方面的处理，那么图形有没有这样的 AI 工具呢？答案是肯定的。

又解锁一款笔记工具：Logseq

Mon, 15 Aug 2022 08:20:20 +0800

我很喜欢去尝试使用一些新的工具，解决一些当下的问题，所以工具永远没有最好，只有最合适，最近一直在使用的 Obsidian 是在范冰的播客中知道的，通过范冰我还知道了另一个笔记工具，也就是今天的主角：Logseq 。

Obsidian 一周使用心得（配置、主题和插件）

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

在上一篇 Obsidian 初体验中介绍了为什么要开始使用 Obsidian 和我的一些基本用法，本文将继续讲解近一个星期以来的使用心得，包括配置、外观和插件。

对于工具类的软件，我一直的方式是先进行基本设置，使用起来，在使用过程中再慢慢发现一些高级用法，就像 Obsidian 这个软件，目的是能方便进行写作，如果花大量精力去研究功能、插件等，就有点本末倒置了。

Obsidian 初体验

Tue, 14 Jun 2022 08:20:20 +0800

我虽然不是工具控，但写作类的工具用过不少，其中 Notion 和 Typora 还专门写文章介绍过：

一款用了就不想走的工具
使用 Typora 进行写作

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

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

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

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

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

Mac中的翻译神器

Mon, 25 Apr 2022 09:59:29 +0800

对程序员来说，英语能力非常重要，但当我们的英语没那么好的时候，就需要借助一些翻译工具来帮我们去阅读英文资料。

翻译工具用过不少，像有道词典、灵格斯、欧路、还有浏览器的插件等，不过最近用过的一款翻译工具让我眼前一亮，就是接下来要介绍的 Bob 。

再谈研发效率提升

Mon, 05 Jul 2021 08:25:00 +0800

最近因为一个版本的发布上线，带着团队兄弟们几乎通宵了，见到了凌晨四点武汉的景色。为什么到这么晚，这背后的原因是值得深思的。归根结底，就是研发效率不高，到了临近上线仍出现各种各样的问题。

关于增效，需要做好这两点

Tue, 06 Apr 2021 08:05:00 +0800

最近两会上都谈论到 996 的问题了，那我们实行 996 ，每个人每天都非常忙碌，是不是就效率很高呢？是不是很多时候都在做一些无价值的事情呢？是不是都在加着班写着 Bug 呢？我认为真相远没有我们想象的那么乐观。

春节后的几次公司会议上都在提「增效」，随着公司的发展，人数变多，各种成本也随之增高，所以通过各种方式来增效，才能有正向的发展。以目前我的观察来看，我觉得可以从两个方面入手：沟通和抓住关键点。

在《怎样提高开发效率》一文中主要说的是开发人员硬技能方面的提升，在上面提到的各种成本中，沟通成本是非常重要的一块，这属于软技能的范畴，也是最容易被忽视的。

沟通体现在很多个方面，这里主要想说下提问和 Bug 描述。

前不久，有项目团队同事在企业微信上问我：怎样拉取镜像来进行测试环境的更新？如果考虑到部门之间应该有良好的沟通的协作，我应该告诉他怎么操作，但为什么有这么低级的问题能被问出来，是一个值得思考的问题：

拉取镜像更新是一个每个开发人员必备的技能，为什么还有人是不会的？
有没有做相应的培训，或者培训了，是否每个人都能够理解？
听的时候理解了，实际操作的时候是不是还是不会？

所有有章可循的、都应该形成规范，进行培训、然后考核，保证不同的人按照文档进行操作能够得出相同的结果，如果有开发人员能主动去探究其中的原理并举一反三，那便是锦上添花了。

对于 Bug 描述经常会出现这样的场景：

实施人员：表单上的选人控件加载部门树很慢；

开发：经过一系列的代码检查、运行调试后回复，我本地很快啊；

开发人员时间花了，但并没有解决问题，在描述 Bug 的时候，需要有更详细的场景和上下文信息，比如：

客户的部门和人员的数据量级是多少？
是所有用户还是特定用户，如果特定用户，是否有什么特殊的权限的设置?
客户使用的浏览器是什么版本？
选人控件本身有没有什么特殊数据范围或权限的设置？

有了更多的信息，开发人员就能有针对性地进行排查，也能更容易解决问题。

Bug 只要能重现，处理起来还比较容易，当遇到偶发 Bug 的时候，更是要尽量提供足够的信息，但很多时候描述却是这样的：

实施人员：客户点击某某操作时，会出现系统异常，我们有时操作也会出现，但不是每次都出现；

开发：不能重现，我怎么排查呢？

实施人员在一线，离现场更近，能知道更多的信息，所以在出现问题时需要尽可能多地提供信息：

系统出现异常提示是有日志记录的，是否有对日志进行过初步的分析？
操作的数据中有没有特殊数据，比如附件、富文本等？
是否能收集到客户用的系统以及浏览器的版本？
是否能收集到客户的操作系统的方式？

如果每个一线实施人员都能够去收集一些有用信息，做下初步的分析，然后将整个过程形成文字内容提交给开发，相信会大大提升解决问题的效率。

至于收集哪些有用信息，怎样来做初步分析，随着慢慢地沉淀，也一样可以形成标准的文档和操作手册。

除了沟通，另一个能提高效率的地方就是在工作中能抓住关键点，根据二八法则，抓住 20% 的关键点就能解决 80% 的问题。

下面是最近团队中发生的两个个事情，正好说明了关键点的重要：

产品代码做重构优化，让开发人员按照思路写出类以及空方法，然后进行评审，但开发人员会比较容易关注细节，一动手就想着对象怎样映射，依赖注入应该怎么进行设置等等，浪费了时间；
让开发排查一个 Bug，我便开会去了，一个多小时回来询问情况，得知还没有解决，还在继续调试代码分析原因，最后发现是一个配置项没有添加导致。

第一件事情的关键点是代码的思路，而不是实现，开发人员和产品负责人的目标和思想需要一致，也就是华为管理哲学中所说的「力出一孔」，如果方向偏了，努力越多，错的越远。

第二件事情的关键点是遇到问题的思考，想清楚之后再动手做，最终的做可能是检查配置、寻求其他人员帮助、或者代码调试。而不是任何问题一上来就进行代码调试。

最后总结下：

1、沟通在工作和生活中无处不在，想想沟通的目的，多换位思考；

2、除了上面说的提问和 Bug 描述，还有代码注释、代码提交备注、技术规范文档等等都属于沟通；

3、方向一致、目标明确做起事来才能最高效；

4、多思考、总结、复盘才能慢慢积累经验，经验丰富了才更容易找到关键点。

希望本文能对您有所启发和帮助！

为什么这么忙，还依然做不好事情

Wed, 30 Sep 2020 09:46:53 +0800

一直都很喜欢《重来》系列，最近出了《重来3：跳出疯狂的忙碌》，第一时间在微信读书中阅读了，让我们印象比较深刻的就是「冷静」和「效率」，本文主要说说效率的问题。

怎样提高开发效率（2018）

Mon, 17 Sep 2018 22:49:03 +0800

开发效率可以从个人开发效率和团队开发效率来谈，抛开自由职业者，但凡在一个公司上班的程序员都必然是在一个团队中工作，所以每个人的个人效率最终都会转化为团队的效率。转化率有多大，取决于团队的凝聚力，每个人的劲是不是在往一处使。

团队效率最重要的是沟通，我经常会碰到这样的情况：

怎样提高开发效率

Sun, 21 Oct 2012 00:00:00 +0800

前言

给你一个任务,限定5天内完成,如果你实际用了6天,可以说是开发效率不高,或者同样的一个任务,你花了6天,而你的同事却只用了4天,也可以说是你的开发效率不高,影响开发效率的因素有很多,下面就我个人的理解来谈谈怎样提高开发效率.

工具

俗话说，工欲善其事必先利其器，使用得心应手的工具必然会提高开发效率，做微软平台开发的肯定离不开VS，就VS本身来说，除了常用功能外一些常用的快捷键一定要能熟练运用，例如下面是我认为比较有用的几个快捷键：

注释： Ctrl + K + C
取消注释： Ctrl + K + U
全屏： Shift + Alt + Ente
设置标签： CTRL + K, CTRL + K
下一个、上一个标签： CTRL + K, CTRL + P 、CTRL + K, CTRL + P
列出成员： Ctrl + J
显示参数信息： Ctrl + Shift + Space
转到定义后返回： Ctrl + –

熟练使用快捷键对于代码编写的速率和跟踪代码的速率会有大大的提高。

有时候开发工具自身的功能受到了限制，这是就需要使用插件来丰富功能，这里推荐两款插件，VS中的ReSharper和SqlServer中的SQL prompt5，ReSharper是功能很强大的一个VS插件，但会拖慢VS的速度，就看怎么去权衡了，我在之前的博文《强大的VS插件—Resharper》做过简单介绍。SQL prompt5是SqlServer的一个插件，功能也非常强大，有很强的智能提示功能，所提供的SQL Search功能可以对数据库对象进行快速查找，还提供代码片段功能，在我之前的博文《SqlServer开发利器—SQL Prompt5》中也做过介绍。

除了我们每天都离不开的VS和SqlServer之外还有一些辅助的开发工具也可以来帮助我们来提高效率，我经常使用的有以下几种：

SqlDbx：很小巧的一款数据库管理工具，但功能非常强大，支持多种数据库，经常使用他的智能提示和生成脚本等功能，但也有缺点，对中文支持的不是很好；
Aptana：该工具可以说是做Web开发的利器了，我有时写JS会用到该工具，有一个亮点之处是智能提示能够显示不同浏览器是否支持；
Free Javascript Editor：可以很方便的写一些简单的HTML和JS代码并运行，可以直接选择JS的代码片段进行执行，对JS的调试也很方便。

还有一些其他的工具也非常有用，比如我在平时的工作中会经常用到Total Commander和Everything：

Total Commander：资源管理器的代替工具，支持多标签，可以很方便的对文件进行操作；
Everything：一款搜索工具，速度奇快，以前也做过介绍《软件推荐：磁盘搜索软件Everything》。

代码沉淀

有点规模的软件公司都会有自己的开发框架，这些框架都是多少年积累的产物，目的就是为了提高开发效率，作为一个开发人员平时对于一些常用的代码也应该有自己的沉淀，不光自己沉淀，在组内也应互相分享，记录这些沉淀的代码就可以根据自己的喜好了，记事本、Word、Excel、OneNote等都可以。沉淀的代码还可以使用VS的代码片段功能来进行管理，VS2010中对代码片段支持的很好，上面提到的SqlServer的插件SQL Prompt5也提供了数据库中的代码片段功能。

VS中给我们提供了很多现成的代码片段，要使用自定义的代码片段最方便的就是使用代码片段制作工具，工具点击此处下载，当然也可以自己创建代码片段文件，然后在VS中导入即可，代码片段文件其实就是一个xml格式的文件，后缀为snippet。

代码质量

代码质量好了，产生的bug就少，和测试的交互也就少了，也就不会因为前面产生的bug而影响后面的进度，效率自然就高了。代码质量可以分三个方面来看：

1 代码出错少，能够正常的运行；

主动学习，提升自我的编程技能；
勤思考，对干过的错要经常总结，一些规范性的原则要牢记，这些常常会出现一些低级错误；
一个任务做完后需要进行充分的自测。

2 代码的运行效率高，在大数据、高并发的时候能够高效运行；

高性能的开发得从点滴做起，不放过每一个细节，可能一个小的细节点就是一个性能的瓶颈；
要有重构代码的习惯，好的代码是重构出来的，高性能的代码也是重构出来的；
多学习一些原理性的知识，不光要知其然还是知其所以然，基础扎实了，一些性能的问题就知道怎么去优化了；
之前翻译过几篇关于C#代码简化的博文，参见《C#/Net代码精简优化技巧（1）》、《C#/Net代码精简优化技巧（2）》、《C#/Net代码精简优化技巧（3）》

3 代码最后的运行结果要和客户的要求一致；

做需求之前把自己的理解跟需求分析进行沟通看是否能达成一致，如果是直接和客户进行沟通可以先做出小Demo，然后给客户演示，根据反馈不断改进；
在做的过程中如果遇到有疑问的地方一定要和需求或客户进行沟通，不要根据自己的想法想当然的去进行代码编写；
必要的时候可以引导客户，我们的主要目的能以最有效的方式帮客户解决问题，不能盲目的按照客户的要求来，有时客户说需要一双雨鞋，可能一把伞就可以解决问题。同样对于需求分析写的文档，开发也需要有质疑的精神。

业务知识学习

做任何的系统都避免不了有业务背景，熟练的了解业务知识可以使我们更清楚的知道我们是在做什么。很多的开发人员可能只喜欢钻研技术，对业务往往没什么兴趣，代码写完了，可能还不知道做出的模块时做什么用的，这样写出来的代码的质量就可想而知了。

学习业务可能很枯燥，但却是一劳永逸的事情，所以不管是否有兴趣，还是应该硬着头皮啃下来；
小组内可以成立兴趣小组，探讨的方式来进行学习，互相分享各自的学习内容，关键是组内的氛围要搞起来；
如果是直接跟客户沟通，需要用客户能听懂的语言，比如图文配合或是一些小Demo，否则当开发术语碰上领域术语就可能都是在对牛弹琴了。

总之，作为一名开发人员，要时刻想着怎样来提高开发效率，开发效率的提高是你在工作中一个良性循环的开始。如果您有好的方法和建议，欢迎一起分享。