Eyemon的博客

大多数情况下，大语言模型没有展现真实的能力，并不是因为它没有这个能力，而是它不清楚用户的真实需求，也不了解用户的个人信息。毕竟，这个世界上能精准表达自己意图是一件颇有门槛的事。如今，新一代生成式AI的通用能力更强，如果不精确表达意图，AI是很容易误解的。只要指令下得正确，AI就可能帮你完成任何事。下面，我们用大白话展开聊聊，有哪些发挥语言模型潜力的使用技巧。其中重点介绍语言模型如何生成长篇故事剧本，以及对大模型的情感刺激。

敏捷团队从转型初始期到完全成熟期的发展并不是一蹴而就的。除了理解成熟度评估指标，敏捷团队也要分阶段把控提升的侧重点，逐步向高成熟度靠拢。本文也针对一线特性团队（Scrum team)的敏捷管理成熟度提供了一套调查问卷。

生成式AI（Generative artificial intelligence）是目前最热门的领域，通过一段时期的学习，我想继续以零门槛的方式，介绍对生成式AI的学习感悟，主要是对概念的理解原理延展，不会对具体的公式、算法和工程进行展开。学习到AI背后的原理可以带来很多乐趣，也可带来宝贵的启发，对其他知识领域同样有作用

如果我们把视野再扩大一些，如何针对产研团队整体敏捷状态进行准确的评估呢？只有找准团队敏捷短板的指示器，才能找对自我提升的好策略，持续实施正确的敏捷动作。

通过这些天的学习，鼎叔尝试用大白话聊聊截止目前对于DeepSeek的理解，包括原理、优势、局限和扩展思考

继续聊聊在整个软件生命周期中，以及各个主要阶段，我们选取哪些关键拆解指标做好研发过程的提效治理

持续交付和软件架构的演进是相辅相成的，互相影响，一同发展。

聪明的工程师一定有办法把他变成“虚荣指标”——看着很好看，但是没有起到促进效益的作用。尤其当我们把度量指标和绩效挂钩时，它很容易被人扭曲成让人误导的解释，以便获得更多的利益

这篇文章分享的未来AI就业的新岗位，李开复先生的文章里有些不太一样的看法，有一定的启发，我用自己的语言提炼下

传统研发质量的管理体系一直有比较大的局限性，在敏捷团队中推动度量常常缺乏成就感。质量管理如果作为独立处罚型部门，难以产生推动质量内建的文化。两种环境下的质量观有哪些关键的差异？

人工智能2.0时代，人会被机器替代的担忧一波又一波。AI时代一定会产生新的商业机会和新的岗位，这些岗位来自人机协作的中间地带，让人类能在职场上更有人性地工作。

借着DevOpsSec的东风，聊聊测试（质量）与安全的关系，以及如何在持续测试中落实安全检测能力

研发的度量，不应该是基于绩效处罚，阻碍创新，而是应该帮助团队自我改进，这需要各个关键角色的自发推动和积极支持。本专辑会先从传统度量的局限性开始剖析，重点阐述如何基于敏捷设计度量指标，让过程改进（质量管理）的工作更加适应敏捷研发，并借助敏捷度量体系高效推动团队的健康运作

热门的AI技术应用不断引起轰动。我们要针对AI新技术进一步学习，可以先从其爆发原点——人工神经网络（Artificial Neural Network，ANN）知识开始理解

进入正式的机器学习科目学习，通常是先从掌握经典算法和概念开始，进而编程实践，如下科目知识属于经典的必学内容

丹尼尔·卡尼曼，是常年热门书籍《思考，快与慢》的作者，在近期的2024年3月27日去世，鼎叔翻出当年做《思考，快与慢》品读会分享的PPT，做一个小小的回顾和纪念。

先从数学和信息论开始，从经典理论和概念进行消化，简单介绍下自己是如何学习和思考其本质的。受限于本人在该领域的知识浅薄，如有错漏，敬请谅解

随着大模型技术的风起云涌，各家大厂和研究机构纷纷开始了大模型在效能提升方面的尝试。复盘一下鼎叔基于前期团队实践的心得，也和不少同行交流过，思路还是很被认同的。大模型在研发效能领域的实践，有喜有忧。喜的是，自然语言表达能力的革新，值得把所有依赖教练推动的敏捷方案都重做一遍；忧的是，如果不掌握敏捷研发的本质理论，不懂敏捷，各种大模型提效实践的成功概率会非常低

测试左移的本质是，既然越早进行质量内建活动，得到的收益越多，为什么不把技术人员的一部分精力放在更早期的环节进行质量推动和把关，总的质量保障收益是更高的。测试右看的本质是，既然验证发布效果是持续改进的动力，为什么不在系统测试结束后，持续投入一定的精力，观察用户对质量的期待是否与认知相符，从而在未来的研发周期采取果断改进行动

效能可视化建设，首先要明确核心用户是谁，他的需求是什么，其次再明确唯一的北极星指标是什么，围绕它来建设质效可视化大盘，切忌不让其他指标喧宾夺主

完成端到端测试（也可以称为系统测试）阶段后，进入灰度发布或正式发布阶段，测试人员除了采集和分析缺陷外，也需要抽出一定精力，持续进行高价值的质量保障活动

阶段性总结下我对ChatGPT的基础理解，算是一篇学习思考笔记吧。其中难免有很多不准确的，或过于简略的地方，将来再迭代学习

如果在测试部门只能推行一个技术建设项目，那鼎叔就会选择“持续测试”。这篇继续聊聊持续测试建设的ROI分析，思考未来的成熟度进阶，以及其他要注意的

如果在测试部门只能推行一个技术建设项目，那鼎叔就会选择“持续测试”

鼎叔感觉大家对于如何敏捷地创建和管理需求是非常感兴趣的，这第六个文章合辑整合了“精益产品需求管理”相关的九篇原创文章，内容非常丰富，欢迎分享给身边受苦受难的产研团队，放下争端，一起搞钱

移动互联网时代把“选择”的暴力推进到极致，就是俗称的“卷”，如果不能占据用户的心智空间，再大规模的现有产品都会被“选择的暴力”摧毁。产品的定位总是客观存在的，正确的产品定位会引领正确的公司运营，没有正确的定位就一定是错误的定位

这篇聊聊我对产品经理这个岗位的看法，以及产品经理如何拥抱敏捷，产品和技术如何形成高效协作的团队

最体现用户对产品的满意程度的指标，是NPS。用户使用自己钟爱的产品会出现WOW时刻，其背后的本质，就是好产品能帮助用户获得成功，从而极大提升NPS。我们不止关注用户使用产品时的体验，还要关心用户使用之后会发生什么

测试人员除了要学习开发人员提供的设计技术文档（用作测试设计的参考）以外，还可以积极参与开发相关的如下重要活动，更早地暴露问题，减轻而非加重开发人员的负担

度量需求的数量和时间比较容易，度量需求大小（颗粒度）要麻烦些，那么，度量需求的价值呢？

提高研发效能的本质，就是带着团队明确度量、无限拆解、刻意练习、自建纪律。

聊聊大模型的幻觉问题。这也是各大公司做大模型实践分享的高频词汇。这个主题也很有趣，它不只是服务品质问题，更可以上升到哲学探讨

度量交付需求的数量和时间相对容易，但度量每个需求的大小则比较难落地，我们需要统一的方法来度量各个团队的需求交付规模，它有利于精细化的组织改进，推动团队以比较舒服的节奏完成承诺，还能稳妥处理紧急需求插入，潜在收益远大于成本

验收测试是质量左移的利器，也是团队各角色对需求形成共识的“语言”。遗憾的是大多数团队没有好好利用这个武器，仅仅把验收测试当成P0用例，在流程最后才使用

主要的用户故事场景，就是测试应优先关注的覆盖场景。本文就聊聊用户故事场景的脑爆梳理方法：用户故事地图

与大家一同探讨了测试团队管理、敏捷转型等方面的内容

TesterHome社区小道消息播客直播间邀请了鼎叔，与大家一同探讨了测试团队管理、敏捷转型等方面的内容

我们继续聊聊刻意练习的实践方法和标准，杰出人物保持动机的技巧，最重要的是解释为什么“天生才华”其实并不存在，唯有刻意练习才能达到自我成就的彼岸

社会上经常出现的两类观念，一个是天才和大师有着常人没有的巨大天赋（这也是自媒体最爱的爽文），一个是只要“刻意练习”一万个小时以上就能成为大师（这是老师和家长最爱的教条），这两种说法都容易误导人。天才并不存在，盲目训练也可能适得其反，但是高效且正确的长期训练可以让普通人在任何方面成为大师

聊聊鼎叔为什么写这本书