黄庄以北 - 文章

豆瓣读书 Top 250

2026-07-07T00:00:00+00:00

豆瓣读书 Top 250</h1>

来源：https://book.douban.com/top250</a></li>
抓取时间：2026-07-07</li>
条目数：250</li> </ul>
排名</th> 书名</th> 评分</th> 评价人数</th> 出版信息</th> 引言</th></tr></thead>

1</td> 红楼梦</a></td> 9.7</td> 465523</td> [清] 曹雪芹著 / 人民文学出版社 / 1996-12 / 59.70元</td> 都云作者痴，谁解其中味？</td></tr>
2</td> 活着</a></td> 9.4</td> 919008</td> 余华 / 作家出版社 / 2012-8 / 28.00元</td> 生的苦难与伟大</td></tr>
3</td> 哈利·波特</a></td> 9.7</td> 137382</td> [英] J·K·罗琳 / 苏农 / 人民文学出版社 / 2008-12 / 498.00元</td> 从9¾站台开始的旅程</td></tr>
4</td> 1984</a></td> 9.4</td> 312883</td> [英] 乔治·奥威尔 / 刘绍铭 / 北京十月文艺出版社 / 2010-4-1 / 28.00</td> 栗树荫下，我出卖你，你出卖我</td></tr>
5</td> 三体全集</a></td> 9.5</td> 217489</td> 刘慈欣 / 重庆出版社 / 2012-1 / 168.00元</td> 地球往事三部曲</td></tr>
6</td> 百年孤独</a></td> 9.3</td> 476282</td> [哥伦比亚] 加西亚·马尔克斯 / 范晔 / 南海出版公司 / 2011-6 / 39.50元</td> 魔幻现实主义文学代表作</td></tr>
7</td> 飘</a></td> 9.3</td> 229733</td> [美国] 玛格丽特·米切尔 / 李美华 / 译林出版社 / 2000-9 / 40.00元</td> 革命时期的爱情，随风而逝</td></tr>
8</td> 动物农场</a></td> 9.3</td> 182138</td> [英] 乔治·奥威尔 / 荣如德 / 上海译文出版社 / 2007-3 / 10.00元</td> 太阳底下并无新事</td></tr>
9</td> 房思琪的初恋乐园</a></td> 9.2</td> 424890</td> 林奕含 / 北京联合出版公司 / 2018-2 / 45.00元</td> 向死而生的文学绝唱</td></tr>
10</td> 三国演义（全二册）</a></td> 9.3</td> 183944</td> [明] 罗贯中 / 人民文学出版社 / 1998-05 / 39.50元</td> 是非成败转头空</td></tr>
11</td> 福尔摩斯探案全集</a></td> 9.3</td> 146446</td> [英] 阿·柯南道尔 / 丁钟华等 / 群众出版社 / 1981-8 / 53.00元/68.00元</td> 名侦探的代名词</td></tr>
12</td> 白夜行</a></td> 9.2</td> 534140</td> [日] 东野圭吾 / 刘姿君 / 南海出版公司 / 2013-1-1 / 39.50元</td> 一宗离奇命案牵出跨度近20年步步惊心的故事</td></tr>
13</td> 邓小平时代</a></td> 9.4</td> 87996</td> 【美】傅高义 (Ezra.F.Vogel) / 冯克利 / 生活·读书·新知三联书店 / 2013-1-18 / 88.00元</td> 个人命运背后的历史变局</td></tr>
14</td> 呐喊</a></td> 9.2</td> 178543</td> 鲁迅 / 人民文学出版社 / 1973-3 / 0.36元</td> 新文学的第一声呐喊</td></tr>
15</td> 小王子</a></td> 9.1</td> 799994</td> [法国] 安东尼·德·圣-埃克苏佩里 / 马振骋 / 人民文学出版社 / 2003-8 / 22.00元</td> 献给长成了大人的孩子们</td></tr>
16</td> 安徒生童话故事集</a></td> 9.3</td> 144842</td> [丹麦] 安徒生 / 叶君健 / 人民文学出版社 / 1997-08 / 25.00元</td> 为了争取未来的一代</td></tr>
17</td> 卡拉马佐夫兄弟</a></td> 9.6</td> 53603</td> 陀思妥耶夫斯基 (Ф.М.Достоевский) / 荣如德 / 上海译文出版社 / 2015-2-1 / CNY 78.00</td> </td></tr>
18</td> 撒哈拉的故事</a></td> 9.2</td> 199834</td> 三毛 / 哈尔滨出版社 / 2003-8 / 15.80元</td> 游荡的自由灵魂</td></tr>
19</td> 失踪的孩子</a></td> 9.2</td> 101703</td> [意] 埃莱娜·费兰特 / 陈英 / 人民文学出版社 / 2018-7 / 62.00元</td> 我的整个生命，只是一场为了提升社会地位的低俗斗争。</td></tr>
20</td> 天龙八部</a></td> 9.2</td> 141303</td> 金庸 / 生活·读书·新知三联书店 / 1994-5 / 96.00元</td> 有情皆孽，无人不冤</td></tr>
21</td> 新名字的故事</a></td> 9.2</td> 113210</td> [意] 埃莱娜·费兰特 / 陈英 / 人民文学出版社 / 2017-4 / 59.00元</td> 探索青年时代的激情、困惑、挣扎、背叛和失去</td></tr>
22</td> 杀死一只知更鸟</a></td> 9.2</td> 163314</td> [美] 哈珀·李 / 高红梅 / 译林出版社 / 2012-9 / 32.00元</td> 有一种东西不能遵循从众原则，那就是——人的良心</td></tr>
23</td> 明朝那些事儿（1-9）</a></td> 9.2</td> 204062</td> 当年明月 / 中国海关出版社 / 2009-4 / 358.20元</td> 不拘一格的历史书写</td></tr>
24</td> 野草</a></td> 9.5</td> 56250</td> 鲁迅 / 人民文学出版社 / 1973-3 / 0.20元</td> 我以这一丛野草，在明与暗，生与死，过去与未来之际，献于友与仇，人与兽，爱者与不爱者之前作证。</td></tr>
25</td> 罗杰疑案</a></td> 9.2</td> 101876</td> [英] 阿加莎·克里斯蒂 (Dame Agatha Christie) / 常禾 / 新星出版社 / 2013-3 / 28.00元</td> </td></tr>
26</td> 中国历代政治得失</a></td> 9.2</td> 83987</td> 钱穆 / 生活·读书·新知三联书店 / 2001 / 12.00元</td> 一部简明的“中国政治制度史”</td></tr>
27</td> 沉默的大多数</a></td> 9.1</td> 161539</td> 王小波 / 中国青年出版社 / 1997-10 / 27.00元</td> 沉默是沉默者的通行证</td></tr>
28</td> 我与地坛</a></td> 9.2</td> 132195</td> 史铁生 / 春风文艺出版社 / 2002-5 / 25.00元</td> 这是你的罪孽与福祉</td></tr>
29</td> 彷徨</a></td> 9.3</td> 75588</td> 鲁迅 / 人民文学出版社 / 1973-3 / 0.37元</td> 路漫漫其修远兮，吾将上下而求索</td></tr>
30</td> 许三观卖血记</a></td> 9.2</td> 203506</td> 余华 / 作家出版社 / 2012-9 / 24.00元</td> </td></tr>
31</td> 白鹿原</a></td> 9.2</td> 127788</td> 陈忠实 / 人民文学出版社 / 2012-9 / 39.00元</td> 一轴关于我们民族灵魂的现实主义画卷</td></tr>
32</td> 悉达多</a></td> 9.1</td> 181903</td> [德] 赫尔曼·黑塞 / 姜乙 / 天津人民出版社 / 2017-1 / 32.00元</td> </td></tr>
33</td> 局外人</a></td> 9.1</td> 274728</td> [法] 阿尔贝·加缪 / 柳鸣九 / 上海译文出版社 / 2010-8 / 22.00元</td> 人生在世，永远也不该演戏作假</td></tr>
34</td> 乡土中国</a></td> 9.2</td> 109343</td> 费孝通 / 上海人民出版社 / 2006-4 / 38.00</td> 中国乡土社会传统文化和社会结构理论研究代表作</td></tr>
35</td> 平凡的世界（全三部）</a></td> 9.0</td> 342137</td> 路遥 / 人民文学出版社 / 2005-1 / 64.00元</td> 中国当代城乡生活全景</td></tr>
36</td> 人类简史</a></td> 9.1</td> 215647</td> [以色列] 尤瓦尔·赫拉利 / 林俊宏 / 中信出版社 / 2014-11 / 68.00元</td> 跟着人类一同走过十万年</td></tr>
37</td> 献给阿尔吉侬的花束</a></td> 9.1</td> 137911</td> [美] 丹尼尔·凯斯 / 陈澄和 / 广西师范大学出版社 / 2015-4 / 36.00元</td> 当声称能改造智能的科学实验选中心智障碍主角</td></tr>
38</td> 围城</a></td> 9.0</td> 462430</td> 钱锺书 / 人民文学出版社 / 1991-2 / 19.00</td> </td></tr>
39</td> 笑傲江湖（全四册）</a></td> 9.1</td> 118599</td> 金庸 / 生活·读书·新知三联书店 / 1994-5 / 76.80元</td> 欲练此功，必先自宫</td></tr>
40</td> 故事新编</a></td> 9.5</td> 52228</td> 鲁迅 / 人民文学出版社 / 1973-12-01 / 0.31 元</td> 拾取古代传说，取一点因由，随意点染</td></tr>
41</td> 东方快车谋杀案</a></td> 9.1</td> 154687</td> [英] 阿加莎·克里斯蒂 / 陈尧光 / 人民文学出版社 / 2006-5 / 18.00元</td> 谋杀诡计惊人，波洛的抉择耐人寻味</td></tr>
42</td> 城南旧事</a></td> 9.1</td> 171742</td> 林海音文 / 中国青年出版社 / 2003-7 / 16.00元</td> 长亭外，古道边，芳草碧连天</td></tr>
43</td> 肖申克的救赎</a></td> 9.1</td> 130672</td> [美] 斯蒂芬·金 / 施寄青 / 人民文学出版社 / 2006-7 / 29.90元</td> 豆瓣电影Top1原著</td></tr>
44</td> 江城</a></td> 9.1</td> 70283</td> [美] 彼得·海斯勒 / 李雪顺 / 上海译文出版社 / 2012-1 / 36.00元</td> 外国人眼中的涪陵</td></tr>
45</td> 朝花夕拾</a></td> 9.1</td> 174137</td> 鲁迅 / 人民文学出版社 / 1973-4 / 0.25元</td> 在纷扰中寻出一点闲静</td></tr>
46</td> 基督山伯爵</a></td> 9.1</td> 138311</td> [法国] 大仲马 / 周克希 / 上海译文出版社 / 1991-12-1 / 43.90元</td> 一个报恩复仇的故事，以法国波旁王朝和七月王朝为背景</td></tr>
47</td> 万历十五年</a></td> 9.0</td> 218685</td> [美] 黄仁宇 / 生活·读书·新知三联书店 / 1997-5 / 18.00元</td> 见微知著，历史观的颠覆</td></tr>
48</td> 艺术的故事</a></td> 9.5</td> 29523</td> [英] 贡布里希 (Sir E.H.Gombrich) / 范景中 / 广西美术出版社 / 2008-04 / 280.00</td> 从最早的洞窟绘画到当今的实验艺术</td></tr>
49</td> 霍乱时期的爱情</a></td> 9.0</td> 312108</td> [哥伦比亚] 加西亚·马尔克斯 / 杨玲 / 南海出版公司 / 2012-9-1 / 39.50元</td> 义无反顾地直达爱情的核心</td></tr>
50</td> 厌女</a></td> 9.1</td> 95692</td> 上野千鹤子 / 王兰 / 上海三联书店 / 2015-1 / 28.00元</td> </td></tr>
51</td> 置身事内</a></td> 9.1</td> 106512</td> 兰小欢 / 上海人民出版社 / 2021-8 / 65.00元</td> </td></tr>
52</td> 射雕英雄传</a></td> 9.1</td> 92755</td> 金庸 / 生活·读书·新知三联书店 / 1999-04 / 47.00元</td> 侠之大者，为国为民</td></tr>
53</td> 月亮和六便士</a></td> 9.0</td> 225422</td> [英] 毛姆 / 傅惟慈 / 上海译文出版社 / 2006-8 / 15.00元</td> 有多少人会经历顿悟，就有更少的人甘愿自我放逐</td></tr>
54</td> 西游记（全二册）</a></td> 9.1</td> 103156</td> 吴承恩 / 黄肃秋注释 / 人民文学出版社 / 2004-8 / 47.20元</td> 神魔皆有人情，精魅亦通世故</td></tr>
55</td> 无人生还</a></td> 9.0</td> 168867</td> [英] 阿加莎·克里斯蒂 / 祁阿红 / 人民文学出版社 / 2008-3 / 19.00</td> 童谣杀人案</td></tr>
56</td> 树上的男爵</a></td> 9.1</td> 71890</td> [意大利]伊塔洛·卡尔维诺 / 吴正仪 / 译林出版社 / 2012-4-1 / 30.00元</td> 是不是真的只有先与人疏离，才能最终与他们在一起？</td></tr>
57</td> 秋园</a></td> 9.0</td> 148811</td> 杨本芬 / 北京联合出版公司 / 2020-6 / 38.00元</td> </td></tr>
58</td> 追风筝的人</a></td> 8.9</td> 827877</td> [美] 卡勒德·胡赛尼 / 李继宏 / 上海人民出版社 / 2006-5 / 29.00元</td> 为你，千千万万遍</td></tr>
59</td> 寻路中国</a></td> 9.0</td> 61466</td> [美] 彼得·海斯勒 / 李雪顺 / 上海译文出版社 / 2011-1 / 33.00元</td> 《纽约客》驻北京记者驾车漫游中国大陆的经历</td></tr>
60</td> 刀锋</a></td> 9.0</td> 102286</td> [英] 毛姆 / 周煦良 / 上海译文出版社 / 2007-3 / 18.00元</td> 一把刀的锋刃不容易越过；因此智者说得救之道是困难的</td></tr>
61</td> 中国少年儿童百科全书（全四册）</a></td> 9.4</td> 21512</td> 林崇德主编 / 浙江教育出版社 / 1991-4 / 168.00元</td> </td></tr>
62</td> 格林童话全集</a></td> 9.1</td> 102288</td> [德]格林兄弟 / 魏以新 / 人民文学出版社 / 1994-11 / 21.45元</td> 一本有教育意义的书</td></tr>
63</td> 可能性的艺术</a></td> 9.2</td> 51115</td> 刘瑜 / 广西师范大学出版社 / 2022-4 / 82.00元</td> </td></tr>
64</td> 太白金星有点烦</a></td> 9.0</td> 150986</td> 马伯庸 / 湖南文艺出版社 / 2023-6 / 45.00</td> </td></tr>
65</td> 一间只属于自己的房间</a></td> 9.2</td> 60871</td> [英] 弗吉尼亚·伍尔夫 / 周颖琪 / 天津人民出版社 / 2019-10 / 39.8元</td> </td></tr>
66</td> 刘擎西方现代思想讲义</a></td> 9.2</td> 46330</td> 刘擎 / 新星出版社 / 2021-1 / 79.00元</td> </td></tr>
67</td> 孽子</a></td> 9.2</td> 59503</td> 白先勇 / 广西师范大学出版社 / 2010-10 / 46.00元</td> 写给那一群，在最深最深的黑夜里，独自彷徨街头，无所依归的孩子们</td></tr>
68</td> 鼠疫</a></td> 9.1</td> 95710</td> [法] 阿尔贝·加缪 / 刘方 / 上海译文出版社 / 2013-8 / 34.00元</td> 用别样的监禁生活再现某种监禁生活，与用不存在的事表现真事同等合理</td></tr>
69</td> 南京大屠杀</a></td> 9.7</td> 29694</td> [美]张纯如（Iris Chang） / 谭春霞 / 中信出版社 / 2015-8 / 49.00元</td> </td></tr>
70</td> 嫌疑人X的献身</a></td> 8.9</td> 554498</td> [日] 东野圭吾 / 刘子倩 / 南海出版公司 / 2008-9 / 28.00</td> 数学好是一种极致的浪漫</td></tr>
71</td> 黄金时代</a></td> 8.9</td> 174140</td> 王小波 / 花城出版社 / 1999-3 / 19.00元</td> 我想爱，想吃，还想在一瞬间变成天上半明半暗的云</td></tr>
72</td> 四世同堂</a></td> 9.4</td> 48519</td> 老舍 / 北京十月文艺出版社 / 2008-7 / 36.00元</td> 北平沦陷时代广大平民的悲惨遭遇</td></tr>
73</td> 毛泽东选集</a></td> 9.6</td> 39174</td> 毛泽东 / 人民出版社 / 1991-6 / 40.00元</td> </td></tr>
74</td> 傲慢与偏见</a></td> 8.9</td> 244286</td> [英] 奥斯丁 / 张玲 / 人民文学出版社 / 1993-7 / 13.00元</td> 所有现代言情小说的母体</td></tr>
75</td> 悲惨世界（上中下）</a></td> 9.1</td> 67537</td> [法] 雨果 / 李丹 / 人民文学出版社 / 1992-6 / 66.00元</td> 现实主义与浪漫主义的至高杰作</td></tr>
76</td> 史记（全十册）</a></td> 9.6</td> 27610</td> （汉）司马迁 / （索隐）司马贞，（正义）张守节 / 中华书局 / 1982-11 / 125.00</td> 史家之绝唱，无韵之离骚</td></tr>
77</td> 台北人</a></td> 9.0</td> 84596</td> 白先勇 / 广西师范大学出版社 / 2010-10 / 38.00元</td> 白先勇短篇小说集</td></tr>
78</td> 诗经</a></td> 9.5</td> 32123</td> 孔丘编订 / 北京出版社 / 2006-7 / 19.90元</td> 思无邪</td></tr>
79</td> 美丽新世界</a></td> 9.1</td> 73232</td> 【英】奥尔德斯·赫胥黎 / 陈超 / 上海译文出版社 / 2017-6 / 45.00元</td> </td></tr>
80</td> 流俗地</a></td> 9.1</td> 45896</td> 【马来西亚】黎紫书 / 北京十月文艺出版社 / 2021-4-1 / 55.00元</td> </td></tr>
81</td> 一个叫欧维的男人决定去死</a></td> 9.1</td> 82126</td> [瑞典] 弗雷德里克·巴克曼 / 宁蒙 / 四川文艺出版社 / 2015-12 / 35.00元</td> 这个发生在瑞典的故事，如生命庆典般绚丽斑斓</td></tr>
82</td> 永恒的终结</a></td> 9.1</td> 55046</td> [美] 艾萨克·阿西莫夫 / 崔正男 / 江苏凤凰文艺出版社 / 2014-9 / 32.00元</td> 关于时间旅行的终极奥秘和恢宏构想</td></tr>
83</td> 明亮的夜晚</a></td> 9.0</td> 74028</td> [韩]崔恩荣 / 叶蕾 / 台海出版社 / 2023-8 / 52</td> </td></tr>
84</td> 绝叫</a></td> 8.9</td> 152930</td> [日] 叶真中显 / 林佩瑾 / 北京联合出版公司 / 2020-7 / 58.00元</td> </td></tr>
85</td> 神雕侠侣</a></td> 8.9</td> 107017</td> 金庸 / 有1996年11月北平第4次印本 / 生活·读书·新知三联书店 / 1994-5 / 76.80元</td> 至情至性，情大于武</td></tr>
86</td> 始于极限</a></td> 9.0</td> 86018</td> [日] 上野千鹤子 / 曹逸冰 / 新星出版社 / 2022-9-20 / 59.00元</td> </td></tr>
87</td> 唐诗三百首</a></td> 9.4</td> 30841</td> 蘅塘退士 / 中华书局 / 1984-07-01 / 0.65</td> 熟读唐诗三百首，不会吟诗也会吟</td></tr>
88</td> 筚路维艰</a></td> 9.5</td> 25216</td> 萧冬连 / 社会科学文献出版社 / 2014-10 / 45.00元</td> </td></tr>
89</td> 灿烂千阳</a></td> 8.9</td> 134746</td> [美] 卡勒德·胡赛尼 / 李继宏 / 上海人民出版社 / 2007-9 / 28.00元</td> 唯有希望与爱可以驱散阴霾</td></tr>
90</td> 美的历程</a></td> 9.2</td> 36565</td> 李泽厚 / 生活·读书·新知三联书店 / 2009-7 / 43.00元</td> 中国美学经典之作</td></tr>
91</td> 历史深处的忧虑</a></td> 9.0</td> 48125</td> 林达 / 生活·读书·新知三联书店 / 1997-5 / 19.00元</td> 窥见美国社会的一扇窗</td></tr>
92</td> 上帝掷骰子吗</a></td> 9.2</td> 37288</td> 曹天元 / 辽宁教育出版社 / 2006-1 / 32.00元</td> 量子物理史话</td></tr>
93</td> 冬牧场</a></td> 9.1</td> 49047</td> 李娟 / 新星出版社 / 2012-6 / 29.80元</td> 阿勒泰的精灵</td></tr>
94</td> 窗边的小豆豆</a></td> 8.9</td> 226731</td> [日] 黑柳彻子著 / 赵玉皎 / 南海出版公司 / 2003-1 / 20.00元</td> 真正懂孩子的教育经</td></tr>
95</td> 棋王·树王·孩子王</a></td> 9.3</td> 36336</td> 阿城 / 江苏凤凰文艺出版社 / 2016-3-1 / 58.00</td> </td></tr>
96</td> 最好的告别</a></td> 9.0</td> 57226</td> [美] 阿图·葛文德（Atul Gawande） / 王一方主编 / 浙江人民出版社 / 2015-7-31 / 54.90元</td> 关于衰老与死亡，你必须知道的常识</td></tr>
97</td> 呼兰河传</a></td> 9.0</td> 91094</td> 萧红 / 百花文艺出版社 / 2005-01 / 19.00</td> 萧红的童年往事</td></tr>
98</td> 离开的，留下的</a></td> 8.9</td> 92854</td> [意] 埃莱娜·费兰特 / 陈英 / 人民文学出版社 / 2017-10 / 62.00元</td> 探索中年的虚无、困惑、野心和近乎残暴的爱</td></tr>
99</td> 西线无战事</a></td> 9.4</td> 32214</td> [德] 埃里希·玛丽亚·雷马克 / 姜乙 / 上海文艺出版社 / 2021-1 / 49.00元</td> </td></tr>
100</td> 哭泣的骆驼</a></td> 9.0</td> 61072</td> 三毛 / 哈尔滨出版社 / 2003-6 / 15.80元</td> 沙漠中寻常的生与死</td></tr>
101</td> 罪与罚</a></td> 9.3</td> 41592</td> [俄] 陀思妥耶夫斯基 / 岳麟 / 上海译文出版社 / 2006-8 / 23.00元</td> 描绘人内心的全部深度</td></tr>
102</td> 人间词话</a></td> 9.1</td> 59168</td> 王国维 / 上海古籍出版社 / 1998-12 / 9.80元</td> 以新眼光评旧文学</td></tr>
103</td> 也许你该找个人聊聊</a></td> 9.0</td> 63441</td> [美]洛莉·戈特利布 / 张含笑 / 上海文化出版社 / 2021-7-28 / 68.00元</td> </td></tr>
104</td> 平面国</a></td> 9.2</td> 38204</td> [英] 埃德温·A·艾勃特 / 鲁冬旭 / 上海文化出版社 / 2020-8 / 39.80元</td> </td></tr>
105</td> 遥远的向日葵地</a></td> 9.1</td> 49216</td> 李娟 / 花城出版社 / 2017-11 / 38.00元</td> </td></tr>
106</td> 叫魂</a></td> 9.2</td> 41861</td> [美] 孔飞力 / 陈兼 / 生活·读书·新知三联书店上海三联书店 / 2014-6 / 38.00元</td> </td></tr>
107</td> 道德经</a></td> 9.5</td> 23161</td> 黄元吉 / 陕西人民出版社 / 1996-10 / 4.50元</td> 中国历史上首部完整的哲学著作</td></tr>
108</td> 文学回忆录</a></td> 9.1</td> 46696</td> 木心讲述 / 广西师范大学出版社 / 2013-1-10 / 98.00元</td> 木心留给世界的礼物</td></tr>
109</td> 少年凯歌</a></td> 9.3</td> 23244</td> 陈凯歌 / 人民文学出版社 / 2001-6 / 10.00元</td> </td></tr>
110</td> 桶川跟踪狂杀人事件</a></td> 9.0</td> 62578</td> [日] 清水洁 / 王华懋 / 四川人民出版社 / 2021-2 / 45.00元</td> </td></tr>
111</td> 昨日的世界</a></td> 9.3</td> 23381</td> [奥地利] 斯蒂芬·茨威格 / 徐友敬 / 上海译文出版社 / 2018-7 / 49.00元</td> </td></tr>
112</td> 受戒</a></td> 9.3</td> 31076</td> 汪曾祺 / 漓江出版社 / 1987-10 / 3.95元</td> 江南乡镇民间生活，健康淳朴的人性</td></tr>
113</td> 茶馆</a></td> 9.2</td> 40598</td> 老舍 / 人民文学出版社 / 2002-1 / 9.80元</td> 清末、民初、抗战胜利以后三个历史时期的北京生活风貌</td></tr>
114</td> 大明王朝1566</a></td> 9.5</td> 22380</td> 刘和平 / 花城出版社 / 2016-7 / 88.00元</td> </td></tr>
115</td> 人生的枷锁</a></td> 9.1</td> 34048</td> [英] 毛姆 / 张柏然 / 上海译文出版社 / 2007-3 / 32.00元</td> 在混沌纷扰的生活漩流中，寻求人生的真谛</td></tr>
116</td> 浪潮之巅</a></td> 9.0</td> 35265</td> 吴军 / 电子工业出版社 / 2011-8 / 55.00元</td> 了解IT领域的入门读物</td></tr>
117</td> 失明症漫记</a></td> 9.0</td> 44914</td> [葡] 若泽·萨拉马戈 / 范维信 / 南海出版公司 / 2014-2 / 29.50元</td> 失明症迅速蔓延，整个城市陷入一场空前的灾难</td></tr>
118</td> 爱你就像爱生命</a></td> 8.8</td> 120856</td> 王小波 / 上海锦绣文章出版社 / 2008-5 / 18.00元</td> 王小波与李银河的两地书</td></tr>
119</td> 我们仨</a></td> 8.8</td> 325445</td> 杨绛 / 生活·读书·新知三联书店 / 2003-7 / 18.80元</td> </td></tr>
120</td> 巨人的陨落</a></td> 8.9</td> 89327</td> [英] 肯·福莱特 / 于大卫 / 江苏凤凰文艺出版社 / 2016-5-1 / CNY 129.80</td> 五个家族，一场战争</td></tr>
121</td> 檀香刑</a></td> 9.3</td> 45592</td> 莫言 / 浙江文艺出版社 / 2017-1 / 56.00元</td> </td></tr>
122</td> 面纱</a></td> 9.0</td> 54739</td> [英] 威廉·萨默塞特·毛姆 / 于大卫 / 江西人民出版社 / 2016-4-1 / 39.8元</td> </td></tr>
123</td> 海子的诗</a></td> 9.0</td> 50310</td> 海子 / 人民文学出版社 / 1999-04 / 15.40</td> </td></tr>
124</td> 看不见的城市</a></td> 9.0</td> 43254</td> [意] 伊塔洛·卡尔维诺 / 张密 / 译林出版社 / 2012-4 / 25.00元</td> </td></tr>
125</td> 13 67</a></td> 9.1</td> 30390</td> 陳浩基 / 皇冠文化出版有限公司 / 2014-6-9 / NTD 350</td> </td></tr>
126</td> 我的天才女友</a></td> 8.8</td> 140669</td> [意] 埃莱娜·费兰特 / 陈英 / 人民文学出版社 / 2017-1 / 42.00元</td> “那不勒斯四部曲”第一部，两个女人，50年的友谊和战争</td></tr>
127</td> 人间草木</a></td> 9.2</td> 38634</td> 汪曾祺 / 江苏文艺出版社 / 2005-01 / 20.00元</td> 我就是要这样香，香得痛痛快快</td></tr>
128</td> 飞鸟集</a></td> 8.9</td> 70892</td> [印] 罗宾德拉纳德·泰戈尔 / 徐翰林 / 哈尔滨出版社 / 2004-6 / 16.80元</td> 一个淡泊清透的世界</td></tr>
129</td> 挽救计划</a></td> 9.1</td> 26619</td> [美] 安迪·威尔 / 耿辉 / 译林出版社 / 2021-9 / 68.00</td> </td></tr>
130</td> 教父</a></td> 9.0</td> 42585</td> [美]马里奥·普佐 / 周汉林 / 译林出版社 / 1997-8 / 23.30元</td> “教父三部曲”电影原著</td></tr>
131</td> 人生的智慧</a></td> 9.1</td> 36195</td> (德)叔本华 / 韦启昌 / 上海人民出版社 / 2008-10-01 / 28.00元</td> 对世俗、实用问题深刻而透彻的讨论</td></tr>
132</td> 地下室手记</a></td> 9.2</td> 39309</td> [俄] 陀思妥耶夫斯基 / 曾思艺 / 浙江文艺出版社 / 2020-5 / 39.80元</td> </td></tr>
133</td> 鹿鼎记</a></td> 8.9</td> 58561</td> 金庸 / 广州出版社花城出版社 / 2008-3 / 108.00元</td> 武侠的解构，流氓的狂欢</td></tr>
134</td> 陆犯焉识</a></td> 8.9</td> 61356</td> 严歌苓 / 作家出版社 / 2011-10 / 35.00元</td> 翻手为苍凉，覆手为繁华</td></tr>
135</td> 边城</a></td> 8.7</td> 243708</td> 沈从文 / 北岳文艺出版社 / 2002-4 / 12.00元</td> 一切充满了善，然而到处是不凑巧</td></tr>
136</td> 十万个为什么</a></td> 9.2</td> 22747</td> 少年儿童出版社 / 1962-12</td> </td></tr>
137</td> 斯通纳</a></td> 8.8</td> 72102</td> [美] 约翰·威廉斯 / 杨向荣 / 上海人民出版社 / 2016-1 / 49.00元</td> 即使不能拥有完美的生活，所幸追求过完整的自我</td></tr>
138</td> 2001：太空漫游</a></td> 9.3</td> 26971</td> [英] 阿瑟·克拉克 / 郝明义 / 上海文艺出版社 / 2019-4-10 / 62.00元</td> </td></tr>
139</td> 克莱因壶</a></td> 8.8</td> 89479</td> [日] 冈岛二人 / 张舟 / 化学工业出版社 / 2019-9 / 48.00元</td> </td></tr>
140</td> 梦里花落知多少</a></td> 8.8</td> 102536</td> 三毛 / 北京十月文艺出版社 / 2007-6 / 28.00元</td> 哀而不伤</td></tr>
141</td> 额尔古纳河右岸</a></td> 8.9</td> 78617</td> 迟子建 / 人民文学出版社 / 2019-6-1 / 32.00元</td> </td></tr>
142</td> 安娜·卡列尼娜</a></td> 9.2</td> 37152</td> [俄] 列夫·托尔斯泰 / 草婴 / 上海文艺出版社 / 2007-8 / 37.00元</td> </td></tr>
143</td> 时间简史</a></td> 8.9</td> 65846</td> [英] 史蒂芬·霍金 / 许明贤 / 湖南科学技术出版社 / 2010-4 / 45.00元</td> 探索时间和空间的核心秘密</td></tr>
144</td> 一句顶一万句</a></td> 8.8</td> 102795</td> 刘震云 / 长江文艺出版社 / 2009-3 / 29.80</td> 一句胜过千年</td></tr>
145</td> 王尔德童话</a></td> 9.1</td> 26058</td> [英] 王尔德 / 王林 / 译林出版社 / 2003-6 / 6.00元</td> 一颗纯美纯善、永难泯灭的童心</td></tr>
146</td> 小径分岔的花园</a></td> 8.9</td> 56722</td> [阿根廷] 豪·路·博尔赫斯 / 王永年 / 上海译文出版社 / 2015-7 / 23.00</td> 一个谜语，谜底正是时间</td></tr>
147</td> 金色梦乡</a></td> 9.0</td> 34659</td> [日] 伊坂幸太郎 / 李彦桦 / 译林出版社 / 2010-9 / 35.00元</td> 伊坂幸太郎代表作</td></tr>
148</td> 绿毛水怪</a></td> 9.1</td> 27860</td> 王小波 / 时代文艺出版社 / 2009-1 / 30.00元</td> 我们好象在池塘的水底，从一个月亮走向另一个月亮</td></tr>
149</td> 强风吹拂</a></td> 9.0</td> 35694</td> [日] 三浦紫苑 / 林佩瑾 / 广西师范大学出版社 / 2015-1-1 / 39.00元</td> 明明这么痛苦，这么难过，为什么就是不能放弃跑步？</td></tr>
150</td> 这些人，那些事</a></td> 8.8</td> 70407</td> 吴念真 / 译林出版社 / 2011-9 / 28.00元</td> 平淡叙述下的惊心动魄</td></tr>
151</td> 长日将尽</a></td> 8.9</td> 46329</td> [英] 石黑一雄 / 冯涛 / 上海译文出版社 / 2018-5 / 48</td> </td></tr>
152</td> 半生缘</a></td> 9.1</td> 39584</td> 张爱玲 / 北京十月文艺出版社 / 2012-6-1 / 29.60元</td> </td></tr>
153</td> 故事</a></td> 9.2</td> 22260</td> [美] 罗伯特·麦基 / 周铁东 / 天津人民出版社 / 2014-9 / 68.00元（有2020年7月34印本）</td> 材质、结构、风格和银幕剧作的原理</td></tr>
154</td> 阿勒泰的角落</a></td> 9.1</td> 25023</td> 李娟 / 万卷出版公司 / 2010-6 / 25.00元</td> 白雪和阳光，青草和白桦林</td></tr>
155</td> 海的女儿</a></td> 9.1</td> 28898</td> 安徒生 / 叶君健 / 上海译文出版社 / 1978年6月 / 0.43</td> </td></tr>
156</td> 你当像鸟飞往你的山</a></td> 8.7</td> 226964</td> [美] 塔拉·韦斯特弗 / 任爱红 / 南海出版公司 / 2019-10 / 59.00元</td> 我来自一个极少有人能想象的家庭，教育给了我新世界</td></tr>
157</td> 经济学原理（上下）</a></td> 9.1</td> 24118</td> [美] 曼昆 / 梁小民 / 机械工业出版社 / 2003-8 / 88.00元</td> 经济学家们的世界观</td></tr>
158</td> 冰与火之歌</a></td> 9.5</td> 22124</td> [美]乔治·R.R.马丁 / 谭光磊 / 重庆出版社 / 2013-10-1 / 330.00元</td> 乔治·R·R·马丁史诗奇幻小说</td></tr>
159</td> 天朝的崩溃</a></td> 9.4</td> 19219</td> 茅海建 / 生活·读书·新知三联书店 / 2014-10 / 59.00元</td> </td></tr>
160</td> 东晋门阀政治</a></td> 9.5</td> 18051</td> 田余庆 / 北京大学出版社 / 2012-5 / 49.00元</td> </td></tr>
161</td> 鹿川有许多粪</a></td> 8.9</td> 42581</td> 李沧东 / 春喜 / 武汉大学出版社 / 2021-8 / 58.00元</td> </td></tr>
162</td> 國史大綱（上下）</a></td> 9.4</td> 17879</td> 錢穆 / 商务印书馆 / 2013-8 / 76.00元</td> 钱穆中国通史</td></tr>
163</td> 我不知道该说什么，关于死亡还是爱情</a></td> 9.2</td> 21949</td> [白俄] S·A·阿列克谢耶维奇 / 方祖芳 / 花城出版社 / 2014-6-15 / 34.80元</td> 真实记录切尔诺贝利核灾难事件</td></tr>
164</td> 万水千山走遍</a></td> 8.9</td> 49501</td> 三毛 / 哈尔滨出版社 / 2003-08 / 13.80</td> 从遥远的撒哈拉到敦煌戈壁</td></tr>
165</td> 草房子</a></td> 9.0</td> 63391</td> 曹文轩 / 江苏少年儿童出版社 / 2009-6 / 18.00元</td> 男孩桑桑刻骨铭心、终身难忘的六年小学生活</td></tr>
166</td> 李光耀观天下</a></td> 9.2</td> 19119</td> 李光耀 / 北京大学出版社 / 2015-6 / 58.00元</td> </td></tr>
167</td> 一个女人的故事</a></td> 9.0</td> 25479</td> [法]安妮·埃尔诺 / 郭玉梅 / 上海人民出版社 / 2022-10 / 38.00</td> </td></tr>
168</td> 天生有罪</a></td> 9.1</td> 25329</td> [南非] 特雷弗·诺亚 / 董帅 / 北京联合出版公司 / 2018-2-1 / 58.00</td> </td></tr>
169</td> 温柔的夜</a></td> 9.1</td> 25832</td> 三毛 / 北京十月文艺出版社 / 2007-5 / 28.00元</td> 三毛在加纳利群岛的生活</td></tr>
170</td> 生死疲劳</a></td> 8.9</td> 66004</td> 莫言 / 浙江文艺出版社 / 2021-11 / 69.90元</td> </td></tr>
171</td> 全球通史</a></td> 9.0</td> 25973</td> 斯塔夫里阿诺斯 / 吴象婴 / 北京大学出版社 / 2012-2-1 / 168.00元</td> </td></tr>
172</td> 史蒂夫·乔布斯传</a></td> 8.8</td> 65271</td> [美] 沃尔特·艾萨克森 / 管延圻 / 中信出版社 / 2011-10-24 / 68.00元</td> 完美主义者的最高形态</td></tr>
173</td> 一个陌生女人的来信</a></td> 8.7</td> 156531</td> [奥] 斯蒂芬·茨威格 / 张玉书 / 上海译文出版社 / 2007-7 / 20.00元</td> 暗恋的极致</td></tr>
174</td> 德米安</a></td> 8.9</td> 46120</td> [德] 赫尔曼·黑塞 / 丁君君 / 上海人民出版社 / 2009-3 / 25.00元</td> 少年辛克莱寻找通向自身之路的艰辛历程</td></tr>
175</td> 苏菲的世界</a></td> 8.8</td> 64402</td> [挪] 乔斯坦·贾德 / 萧宝森 / 作家出版社 / 2007-10 / 26.00元</td> 哲学启蒙书</td></tr>
176</td> 亮剑</a></td> 9.0</td> 34399</td> 都梁 / 解放军文艺出版社 / 2005-3 / 28.00元</td> 面对强大的对手，明知不敌，也要毅然亮剑</td></tr>
177</td> 亲密关系（第6版）</a></td> 9.2</td> 32468</td> [美] 罗兰·米勒 / 王伟平 / 人民邮电出版社 / 2015-6 / 138.00元</td> </td></tr>
178</td> 看不见的女性</a></td> 9.2</td> 23401</td> 卡罗琳·克里亚多·佩雷斯 / 詹涓 / 新星出版社 / 2022-8 / 69.00元</td> </td></tr>
179</td> 康熙的红票</a></td> 9.3</td> 16807</td> 孙立天 / 商务印书馆 / 2024-3 / 78</td> </td></tr>
180</td> 包法利夫人</a></td> 9.1</td> 36104</td> 福楼拜 / 李健吾 / 人民文学出版社 / 2003-1-1 / CNY 28.00</td> </td></tr>
181</td> 爱的艺术</a></td> 8.8</td> 56925</td> [美] 艾·弗洛姆 / 李健鸣 / 上海译文出版社 / 2008-4 / 15.00元</td> 谦恭地、勇敢地、真诚地和有纪律地爱他人</td></tr>
182</td> 球状闪电</a></td> 8.7</td> 96878</td> 刘慈欣 / 四川科学技术出版社 / 2005-6 / 22.00元</td> 量子之外，没有真相</td></tr>
183</td> 恶意</a></td> 8.7</td> 166888</td> [日] 东野圭吾 / 娄美莲 / 南海出版公司 / 2016-11 / 39.50元</td> </td></tr>
184</td> 倾城之恋</a></td> 8.9</td> 45837</td> 张爱玲 / 北京十月文艺出版社 / 2012-6-1 / 29.80元</td> </td></tr>
185</td> 帷幕</a></td> 9.2</td> 22699</td> [英] 阿加莎·克里斯蒂 (Dame Agatha Christie) / 李杨 / 新星出版社 / 2015-2 / 26.00元</td> </td></tr>
186</td> 我的阿勒泰</a></td> 8.9</td> 35268</td> 李娟 / 云南人民出版社 / 2010-7 / 25.00元</td> 描写疆北阿勒泰地区生活和风情的原生态散文集</td></tr>
187</td> 不能承受的生命之轻</a></td> 8.8</td> 51215</td> 米兰·昆德拉 / 许钧 / 上海译文出版社 / 2010-8 / 29.00元</td> </td></tr>
188</td> 古文观止</a></td> 9.1</td> 20590</td> 吴楚材 / 中华书局 / 1987-1-1 / 21.00元</td> 收录自先秦至明末的散文二百二十二篇</td></tr>
189</td> 麦琪的礼物</a></td> 8.7</td> 80395</td> [美] 欧·亨利 / 张经浩 / 上海社会科学院出版社 / 2003-7 / 25.00元</td> 日常的奇迹</td></tr>
190</td> 社会心理学</a></td> 9.0</td> 29242</td> [美] 戴维·迈尔斯 / 张智勇 / 人民邮电出版社 / 2006-1 / 68.00元</td> 人们是如何思索、影响他人并与他人建立联系的</td></tr>
191</td> 足利女童连续失踪事件</a></td> 9.0</td> 31516</td> [日] 清水洁 / 曾玉婷 / 文汇出版社 / 2022-7 / 49.00元</td> </td></tr>
192</td> 雕刻时光</a></td> 9.4</td> 11568</td> [苏] 安德烈·塔可夫斯基 / 张晓东 / 南海出版公司 / 2016-5 / 45.00元</td> </td></tr>
193</td> 父权制与资本主义</a></td> 9.2</td> 22196</td> [日] 上野千鹤子 / 邹韵 / 浙江大学出版社 / 2020-3 / 58.00元</td> </td></tr>
194</td> 银河帝国：基地七部曲</a></td> 9.5</td> 19587</td> [美] 艾萨克·阿西莫夫 / 叶李华 / 江苏凤凰文艺出版社 / 2015-10-1 / 328.00元</td> 阿西莫夫经典科幻小说</td></tr>
195</td> 一桩事先张扬的凶杀案</a></td> 8.7</td> 66074</td> [哥伦比亚] 加西亚·马尔克斯 / 魏然 / 南海出版公司 / 2013-6 / 25.00元</td> 我如此急切地想要讲述这桩案件，也许是它最终确定了我的作家生涯</td></tr>
196</td> 我也有一个梦想</a></td> 9.0</td> 16990</td> 林达 / 生活·读书·新知三联书店 / 2004-08 / 25.00元</td> 在法治国家里，民众怎样运用法律</td></tr>
197</td> 跨越边界的社区（修订版）</a></td> 9.4</td> 12493</td> 项飙 / 生活·读书·新知三联书店 / 2018-3 / 68.00元</td> </td></tr>
198</td> 在细雨中呼喊</a></td> 8.8</td> 93067</td> 余华 / 作家出版社 / 2012-11-1 / 25.00元</td> </td></tr>
199</td> 激荡三十年（上）</a></td> 8.8</td> 33828</td> 吴晓波 / 中信出版社 / 2007-1 / 35.00</td> 这是一个最好的时代，也是一个最坏的时代</td></tr>
200</td> 当呼吸化为空气</a></td> 8.9</td> 35153</td> [美] 保罗·卡拉尼什 / 何雨珈 / 浙江文艺出版社 / 2016-11 / 48.00元</td> 你在死亡中探究生命的意义，你见证生前的呼吸化作死后的空气</td></tr>
201</td> 雷雨</a></td> 8.7</td> 86067</td> 曹禺 / 人民文学出版社 / 1999-05 / 9.20</td> 一幕人生大悲剧，在一个雷雨夜爆发</td></tr>
202</td> 奥斯维辛</a></td> 9.5</td> 12407</td> [英] 劳伦斯·里斯 / 刘爽 / 广西师范大学出版社 / 2016-9 / 79.00元</td> </td></tr>
203</td> 从零开始的女性主义</a></td> 8.7</td> 79516</td> [日本] 上野千鹤子 / 吕灵芝 / 北京联合出版公司 / 2021-9 / 52.00元</td> </td></tr>
204</td> 理想国</a></td> 8.8</td> 41824</td> [古希腊] 柏拉图 / 郭斌和 / 商务印书馆 / 1986-8 / 28.00元</td> 人类历史上最早的乌托邦</td></tr>
205</td> 尼罗河上的惨案</a></td> 8.7</td> 55578</td> [英] 阿加莎·克里斯蒂 / 宫英海 / 人民文学出版社 / 2006-5 / 22.00元</td> 阿加莎·克里斯蒂代表作</td></tr>
206</td> 骆驼祥子</a></td> 8.6</td> 227460</td> 老舍 / 人民文学出版社 / 1962-10-1 / 12.00元</td> 旧中国老北京贫苦市民的典型命运</td></tr>
207</td> 变形记</a></td> 9.2</td> 25336</td> [奥地利] 弗朗茨·卡夫卡 / 彤雅立 / 北京燕山出版社 / 2020-1-1 / 45.00</td> </td></tr>
208</td> 海风中失落的血色馈赠</a></td> 9.0</td> 23118</td> [加拿大] 阿利斯泰尔·麦克劳德 / 陈以侃 / 上海文艺出版社 / 2015-6-1 / CNY 20.00</td> 男女之间、父母与子女之间紧密的纽带和难以逾越的鸿沟</td></tr>
209</td> 一千零一夜</a></td> 8.8</td> 64251</td> 纳训 / 人民文学出版社 / 2003-01 / 22.00</td> 阿拉伯地区的古代民间传说</td></tr>
210</td> 雨季不再来</a></td> 8.8</td> 60321</td> 三毛 / 北京十月文艺出版社 / 2007-7 / 28.00元</td> 三毛少女时代的成长感受</td></tr>
211</td> 荒原狼</a></td> 9.0</td> 27367</td> [德]赫尔曼·黑塞 / 赵登荣 / 上海译文出版社 / 2008-7 / 13.00</td> “超现实主义”风格作品，德国的《尤利西斯》</td></tr>
212</td> 万物有灵且美</a></td> 8.9</td> 24898</td> [英] 吉米·哈利 / 种衍伦 / 中国城市出版社 / 2010-1 / 28.80</td> 活泼的生命完全无须借助魔法，便能对我们述说至美至真的故事</td></tr>
213</td> 情书</a></td> 8.6</td> 114386</td> [日] 岩井俊二 / 穆晓芳 / 天津人民出版社 / 2004-7 / 18.00元</td> 一场同名同姓的误会，两段可贵的爱情</td></tr>
214</td> 翦商</a></td> 8.8</td> 39125</td> 李硕 / 广西师范大学出版社 / 2022-10 / 99.00元</td> </td></tr>
215</td> 倚天屠龙记</a></td> 8.7</td> 66756</td> 金庸 / 生活·读书·新知三联书店 / 1999-04 / 47.00</td> 不识张郎是张郎</td></tr>
216</td> 水浒传（全二册）</a></td> 8.7</td> 86503</td> [明] 施耐庵 / 人民文学出版社 / 1997-1 / 50.60元</td> 替天行道</td></tr>
217</td> 最好的我们</a></td> 8.7</td> 76881</td> 八月长安 / 湖南文艺出版社 / 2013-8-5 / 55</td> 耿耿余淮</td></tr>
218</td> 孙子兵法</a></td> 9.4</td> 15710</td> 孙武 / 郭化若 / 上海古籍出版社 / 2006-7 / 20.00元</td> 我国最古老最杰出的一部兵书</td></tr>
219</td> 坟</a></td> 9.6</td> 14386</td> 鲁迅 / 人民文学出版社 / 2006-12 / 16.00元</td> </td></tr>
220</td> 庄子</a></td> 9.4</td> 13917</td> 孙通海译注 / 孙通海译注 / 中华书局 / 2007-04 / 20.00元</td> 野马也，尘埃也，生物之以息相吹也</td></tr>
221</td> 现代艺术150年</a></td> 9.1</td> 16830</td> [英] 威尔·贡培兹 / 王烁 / 广西师范大学出版社 / 2017-3 / 65.00元</td> </td></tr>
222</td> 她对此感到厌烦</a></td> 9.0</td> 30774</td> 妚鹤 / 北京联合出版公司 / 2023-4 / 54.80元</td> </td></tr>
223</td> 黑箱：日本之耻</a></td> 8.9</td> 26938</td> [日] 伊藤诗织 / 匡匡 / 雅众文化/中信出版集团 / 2019-4 / 48.00元</td> </td></tr>
224</td> 送你一颗子弹</a></td> 8.6</td> 147093</td> 刘瑜 / 上海三联书店 / 2010-1 / 25.00元</td> 在这本书里，被“审视”的东西杂七杂八</td></tr>
225</td> 不存在的骑士</a></td> 8.9</td> 30806</td> [意] 伊塔洛·卡尔维诺 / 吴正仪 / 译林出版社 / 2012-4 / 22.00元</td> </td></tr>
226</td> 论语</a></td> 9.1</td> 26975</td> 刘胜利 / 中华书局 / 2006-12 / 9.80元</td> 仁远乎哉？我欲仁，斯仁至矣</td></tr>
227</td> 会饮篇</a></td> 9.3</td> 14475</td> [古希腊] 柏拉图 / 王太庆 / 商务印书馆 / 2013-1 / 12.00元</td> </td></tr>
228</td> 白痴</a></td> 9.3</td> 16519</td> [俄] 陀思妥耶夫斯基 / 荣如德 / 上海译文出版社 / 2015-1 / 68.00</td> </td></tr>
229</td> 红星照耀中国</a></td> 9.2</td> 27920</td> [美] 埃德加·斯诺埃 / 董乐山 / 人民文学出版社 / 2016-6 / 43.00元</td> </td></tr>
230</td> 九州·缥缈录</a></td> 8.8</td> 33353</td> 江南 / 新世界出版社 / 2005-6 / 20.00元</td> 乱世的英雄史诗</td></tr>
231</td> 罗生门</a></td> 8.7</td> 76850</td> [日] 芥川龙之介 / 林少华 / 上海译文出版社 / 2008-7 / 12.00元</td> 人生，远比地狱更像地狱</td></tr>
232</td> 金锁记</a></td> 8.7</td> 68834</td> 张爱玲 / 哈尔滨出版社 / 2005-6 / 13.5元</td> 一个小商人家庭出身的女子曹七巧的心灵变迁历程</td></tr>
233</td> 孩子你慢慢来</a></td> 8.7</td> 83359</td> 龙应台 / 生活·读书·新知三联书店 / 2009-12-1 / 28.00元</td> 我们现在怎样做母亲</td></tr>
234</td> 显微镜下的大明</a></td> 8.7</td> 58079</td> 马伯庸 / 湖南文艺出版社 / 2019-1 / 52.00元</td> </td></tr>
235</td> 二手时间</a></td> 8.9</td> 29366</td> [白俄] S. A. 阿列克谢耶维奇 / 吕宁思 / 中信出版社 / 2016-1 / 55.00元</td> </td></tr>
236</td> 渴望生活</a></td> 9.1</td> 12513</td> [美] 欧文·斯通 / 常涛 / 北京十月文艺出版社 / 2008-4 / 29.80元</td> 梵高悲惨而成就辉煌的人生</td></tr>
237</td> 分成两半的子爵</a></td> 8.8</td> 34732</td> [意] 伊塔洛·卡尔维诺 / 吴正仪 / 译林出版社 / 2012-4-1 / 20.00元</td> </td></tr>
238</td> 你好，旧时光（上下）</a></td> 8.7</td> 52642</td> 八月长安 / 新世界出版社 / 2009-12 / 39.80元</td> 原作名切题</td></tr>
239</td> 规训与惩罚</a></td> 9.3</td> 12692</td> [法] 米歇尔·福柯 / 刘北成 / 生活·读书·新知三联书店 / 2003-1 / 21.80元</td> </td></tr>
240</td> 浮生六记</a></td> 8.7</td> 75802</td> （清）沈复 / 人民文学出版社 / 1999-1 / 38</td> 苟不记之笔墨，未免有辜彼苍之厚</td></tr>
241</td> 成为波伏瓦</a></td> 9.0</td> 21331</td> [英] 凯特·柯克帕特里克 / 刘海平 / 中信出版社 / 2021-3 / 78.00元</td> </td></tr>
242</td> 你一生的故事</a></td> 8.7</td> 41139</td> [美] 特德·姜 / 李克勤 / 译林出版社 / 2015-5 / 36.00元</td> 特德·姜科幻小说集</td></tr>
243</td> 火星救援</a></td> 8.9</td> 23456</td> [美] 安迪·威尔 / 陈灼 / 译林出版社 / 2015-10 / 38.00</td> </td></tr>
244</td> 哈姆莱特</a></td> 8.7</td> 54950</td> [英] 莎士比亚 / 朱生豪 / 人民文学出版社 / 2001-1 / 7.00元</td> 生存还是毁灭，这是一个值得思考的问题</td></tr>
245</td> 时间的秩序</a></td> 8.9</td> 25151</td> [意] 卡洛·罗韦利 / 杨光 / 湖南科学技术出版社 / 2019-6 / 56.00元</td> </td></tr>
246</td> 象棋的故事</a></td> 9.1</td> 14748</td> [奥] 斯蒂芬·茨威格 / 张玉书 / 上海译文出版社 / 2007-7 / 23.00元</td> 纳粹法西斯对人心灵的折磨及摧残</td></tr>
247</td> 打开一颗心</a></td> 9.1</td> 14846</td> [英] 斯蒂芬·韦斯塔比 / 高天羽 / 广西师范大学出版社 / 2022-4 / 56</td> </td></tr>
248</td> 野火集</a></td> 8.7</td> 36155</td> 龙应台 / 文汇出版社 / 2005-8 / 25.00元</td> 中国人，你为什么不生气</td></tr>
249</td> 贾想 I</a></td> 9.1</td> 15742</td> 贾樟柯 / 台海出版社 / 2017-6-1 / 49.00元</td> </td></tr>
250</td> 银河系漫游指南</a></td> 8.8</td> 24351</td> [英] 道格拉斯·亚当斯 / 徐百柯 / 四川科学技术出版社 / 2005-6 / 16.00元</td> </td></tr> </tbody></table>

推荐一款古籍阅读神器：识典古籍 APP

2026-03-31T00:00:00+00:00

推荐一款古籍阅读神器：识典古籍 APP</h1>

用科技传承文化，让古籍触手可及</p> </blockquote>

为什么推荐它</h2>
如果你和我一样，喜欢历史，喜欢国学，偶尔翻翻经史子集，那么这款APP在行业里基本是没有敌手的。</p>
重要的事情说三遍：免费！免费！免费!</p>
字节跳动公益开发的这个应用基本就是双赢：用户免费享受了高质量的古籍资源，字节训练了自己的AI模型（里面有大量的AI能力应用）。</p>

核心亮点</h2>
1. 海量资源，免费开放</h3>
截至 2026 年 1 月，平台已上线 4.7 万部</strong> 古籍资源，涵盖：</p>

经部（儒家经典）</li>
史部（二十四史等）</li>
子部（诸子百家）</li>
集部（诗文词赋）</li>
道教部（《道德经》各版本）</li>
佛教部（佛经典藏）</li> </ul>
珍贵资源包括：</strong></p>

《永乐大典》高清影像</li>
帛书版《道德经》</li>
哈佛燕京图书馆珍贵馆藏</li>
法藏敦煌文献（正在整理）</li> </ul>
2. AI 技术加持，阅读门槛大幅降低</h3>
技术</th> 准确率</th> 作用</th></tr></thead>

AI OCR 文字识别</td> 96%-97%</td> 古籍图片转文本</td></tr>
自动标点</td> 94%</td> 文言文自动断句</td></tr>
命名实体识别</td> -</td> 识别人名、地名、官职、时间</td></tr>
AI自动译文</td> -</td> 文白对照，自动生成白话翻译</td></tr>
AI朗读</td> -</td> AI朗读古籍文本，支持多种声音选择</td></tr>
AI智能体</td> -</td> 深度研究助手，提供内容总结、疑问解答、跨文献关联检索</td></tr> </tbody></table>
3. 图文对照，还原古籍原貌</h3>
阅读页面点击右下角“原图“图标，可随时切换影印版原图</strong>与数字化文本</strong>对照。</p>
这对于研究者或版本爱好者非常重要——你可以看到：</p>

原书的版式、字体</li>
注疏的位置和格式</li>
不同版本的差异</li> </ul>
4. 文白对照，轻松读懂</h3>
打开“白话文模式“，一句原文配一句白话翻译。</p>
对于晦涩的注疏、古奥的经典，这个功能能帮你快速理解。当然，如果你更喜欢直接读原文，可以一键关闭翻译。</p>
5. 深度研究助手（AI 智能体）</h3>
2026 年新上线的功能，基于豆包大模型：</p>

对 3.6 万部收录古籍进行深度挖掘</li>
智能分析、跨文献关联检索</li>
解答古文疑问、提供内容总结</li> </ul>

阅读体验</h2>
个性化设置</h3>

简体/繁体切换</li>
注疏展开/隐藏</li>
字号调整</li>
背景切换（含夜间模式）</li>
翻页方式设置</li> </ul>
笔记与同步</h3>

划线标注</li>
添加笔记</li>
书架管理</li>
多端同步</strong>（APP 与网页版数据互通）</li> </ul>
检索功能</h3>
支持多种检索方式：</p>

关键词搜索</li>
按作者检索</li>
按朝代筛选</li>
主题词检索</li>
兴趣分类浏览（热门榜单、书单推荐）</li> </ul>
播客结合</h3>
在一些热门古籍中，直接提供了相关的播客内容，可以边听边读。</p>

与其他平台的对比</h2>
特性</th> 识典古籍</th> 传统古籍平台</th></tr></thead>

费用</td> 完全免费</td> 部分收费/会员制</td></tr>
广告</td> 无</td> 常见</td></tr>
OCR 准确率</td> 96%-97%</td> 93%-94%</td></tr>
图文对照</td> 支持</td> 部分支持</td></tr>
文白对照</td> 支持</td> 少数支持</td></tr>
AI 助手</td> 深度研究助手</td> 较少</td></tr>
多端同步</td> 支持</td> 部分支持</td></tr> </tbody></table>

适合谁用</h2>
强烈推荐：</strong></p>

古典文学爱好者</li>
历史研究者</li>
哲学/思想史学习者</li>
书法/版本学爱好者</li>
想读古籍但被文言文门槛劝退的人</li> </ul>
可能不太需要：</strong></p>

只读现代白话文的用户</li>
对传统文化完全无兴趣的人</li> </ul>

下载方式</h2>
iOS：</strong> App Store 搜索“识典古籍“</p>
Android：</strong> 各应用商店搜索“识典古籍“，或访问官网下载</p>
网页版：</strong> www.shidianguji.com</a> 这个网页版基本上就是PK掉了所有其它同行。</p>

一些感受</h2>
识典古籍 APP 解决了我几个痛点：</p>

听书问题：我喜欢在通勤或休息时听书，现在的AI朗读还比较有感情。</li>
多端同步：可以随时随地换设备继续阅读，解决了我这种设备党的痛。</li> </ol>

结语</h2>
如果你也喜欢历史，国学，或者家里有正在应试教育中的娃(四大名著里面也有)，非常推荐安装体验一下。</p>

相关链接：</strong></p>

官网：https://www.shidianguji.com</li>
知乎使用指南：https://zhuanlan.zhihu.com/p/1930585634730386921</li>
百度百科：https://baike.baidu.com/item/识典古籍/62115747</li> </ul>

2026-03-31</em></p>

Booklist For AI

2026-03-20T00:00:00+00:00

Booklist For AI</h1>
《谈谈方法》—— 笛卡尔
重点：如何独立思考、怀疑、求真
《猜想与反驳》—— 波普尔（可读精简本）
重点：什么是知识？AI 能产生真正的知识吗？
《简单的逻辑学》/《学会提问》
重点：识别谬误、看穿话术、AI 回答的漏洞</p>
《存在主义是一种人道主义》—— 萨特
重点：人不是被设定的，你自己定义自己
《西西弗神话》—— 加缪
重点：AI 时代，人为什么还要努力、意义从哪来
《道德形而上学基础》（精简读本）—— 康德
重点：人永远是目的，不是工具（对抗 AI 工具化）
《公正》—— 迈克尔・桑德尔（最通俗）
重点：帮你快速建立现代伦理框架</p>
《倦怠社会》《透明社会》—— 韩炳哲（极强、极短）
重点：算法、效率、信息对人的压迫
《今日简史》—— 赫拉利
重点：数据主义、AI 对人类价值的颠覆
《技术与时间》（可选，偏深）—— 斯蒂格勒
重点：技术如何改变人的意识与记忆
《你当像鸟飞往你的山》（偏文学）
重点：在信息洪流里，如何守住自我</p>

AI 技术链接收集

2026-03-05T00:00:00+00:00

2026-09-11</h2>
Kotlin“J神”两小时争议访谈：我宁愿失去80%的工作机会，也坚决不用 AI 编程</a></h3>
来源：</strong> InfoQ 时间：</strong> 2026-09-11</p>
核心内容：</strong></p>

Kotlin 与 Android 开源大神 Jake Wharton 解释其拒绝加入 AI 公司和反对强制 AI 编程的原因，并讨论 Kotlin、Java、Swift、Rust、开源生态及工程师职业选择。</p> </blockquote>
技术要点：</strong></p>

Wharton 认为 AI 可辅助重复劳动，但若生成超出开发者理解和维护能力的代码，会削弱工程责任、技能与议价权。</li>
他质疑管理层自上而下强制采用 AI，指出这不同于 Kotlin、IDE 等工具由工程师基于实际价值自下而上推广的传统。</li>
Kotlin 的核心优势不只是减少样板代码，还包括 Java 互操作、可空类型、成熟 IDE、工具链与开源生态；Java 的快速演进则持续缩小语言差距。</li>
他更欣赏 Swift 的错误处理和内存表示，以及 Rust 将所有权、资源责任和失败模式纳入类型系统的设计。</li>
AI 生成代码不会取代共享开源库的长期价值：公共依赖能集中修复缺陷、持续优化性能，并让改进惠及所有使用者。</li> </ul>
应用场景：</strong></p>

适合关注 AI 编程治理、工程师职业发展、Kotlin 生态与开源维护策略的开发者和技术管理者阅读。</p> </blockquote>
原文链接：</strong> 📌 保存链接</a></p>

2026-08-12</h2>
“写代码从来都不是难点”？25年开发者怒写3000字反驳：这句话是对所有程序员的一种侮辱！</a></h3>
来源：</strong> ImportNew（转自 CSDN）时间：</strong> 2026-08-12</p>
核心内容：</strong></p>

文章围绕“编码并非软件开发难点”的流行论调展开争论：AI 虽在降低代码生成门槛，但优秀编码仍是需要经验、判断和耐心的手艺，复杂系统的维护与演进也不会因此变得简单。</p> </blockquote>
技术要点：</strong></p>

25 年经验开发者 Senko Rašić 认为，编码的稀缺性、高薪、学习门槛、复杂度与长期 Bug 现实，都反驳了“写代码很简单”的笼统说法。</li>
软件成功既依赖用户理解、需求澄清和组织协作，也依赖可靠实现；二者不应被制造成非此即彼的对立。</li>
AI 会持续改变程序员职责，但软件复杂性、维护成本、技术迭代以及客户需求的不确定性不会消失。</li>
资深开发者应拓展用户体验、客户访谈和商业策略能力；新人仍应深入学习指针、递归、内存、网络协议、算法与数据结构。</li>
关键原则是不要把理解力、判断力、共情力与品味外包给 AI，而要在使用工具的同时保留工程责任。</li> </ul>
应用场景：</strong></p>

适合关注 AI 编程、软件工程职业演变、开发者能力建设和技术团队管理的人阅读。</p> </blockquote>
原文链接：</strong> 📌 保存链接</a></p>

2026-07-23</h2>
梁文锋4小时闭门实录，读懂AI长期机会</a></h3>
来源：</strong> 瑞泽洞察时间：</strong> 2026-07-23</p>
核心内容：</strong></p>

文章整理梁文锋4小时闭门投资人交流的20条观点，聚焦AGI路线、持续学习、算力差距、国产芯片、开源策略、商业化克制与团队稳定等长期AI机会。</p> </blockquote>
技术要点：</strong></p>

AGI路线被概括为 CoT → Agent → 持续学习 → 自我迭代奇点 → 具身智能；当前最大短板是持续学习能力，而非单点多模态或视频生成能力。</li>
Scaling 尚未触及上限，国内模型规模主要受算力资源约束；中美差距更集中在资源与实验机会，而非人才本身。</li>
CUDA 护城河可能因 AI 编程与 TileLang 等高级算子语言被削弱，国产芯片生态有机会通过软件栈重构追赶。</li>
华为超节点被视为可在价格/性能上替代部分英伟达集群，但仍存在硬件代差；算力短板需靠算法降耗与国产硬件迭代双向缓解。</li>
国内基座模型厂商未来可能自然收敛至少数具备完整研发能力的玩家；中国AI长期优势在低成本推理和本土产品体验。</li>
开源被描述为底层愿景的一部分，强调开源模型与线上部署模型一致；API定价追求合理回本而非利润最大化。</li>
组织层面强调团队稳定、共识决策和长期克制，认为保持团队不散是实现AGI的核心条件。</li> </ul>
应用场景：</strong></p>

适合AI创业者、从业者和投资者理解大模型公司长期技术路线、算力格局与组织战略判断。</p> </blockquote>
原文链接：</strong> 📌 保存链接</a></p>

2026-07-12</h2>
连Claude Code都搞不定的巨型代码库，我们靠一个“自愈循环”给盘活了</a></h3>
来源：</strong> InfoQ 时间：</strong> 2026-07-12 10:15</p>
核心内容：</strong></p>

ServiceTitan 在遗留报告指标迁移中，用可验证的小任务、自愈循环和并行 Agent 流水线，让 85% 迁移工作由 AI 自主完成，将周期从数季度压缩到数周。</p> </blockquote>
技术要点：</strong></p>

核心不是让 Claude Code/Cursor 直接理解并改造整个巨型代码库，而是把迁移拆到 AI 能独立完成、可自动验证的粒度。</li>
迁移流水线强调强验证器：每个增量步骤都必须能确认代码是否正确运行，避免大规模并行执行时偏离轨道。</li>
给 coding agent 的任务要足够简单，并把复杂性隐藏在验证步骤、上下文准备和工具链背后。</li>
ServiceTitan 的案例聚焦报告指标从遗留系统迁移到 DBT MetricFlow / Semantic Layer 等新架构，涉及旧代码、数据库表依赖、真实数据形态和分片等上下文。</li>
“自愈循环”思路是让 Agent 生成代码、运行验证、读取失败原因并迭代修复；人类工程师主要处理剩余复杂案例与架构决策。</li>
结果显示约 85% 迁移可由 AI 自主完成，剩余 15% 交由工程师介入，项目反馈周期从季度级缩短到周级。</li> </ul>
应用场景：</strong></p>

适合需要批量迁移遗留代码、指标/报表系统或大型架构改造的工程团队，用 Agent 加速但仍以验证闭环控制风险。</p> </blockquote>
原文链接：</strong> 📌 保存链接</a></p>

2026-07-01</h2>
吴恩达戳破AI幻象：炒作过头了，未来公司是10人小队＋Agent重做数据架构</a></h3>
来源：</strong> AI前线 / 微信公众号时间：</strong> 2026-07-01</p>
核心内容：</strong></p>

文章整理吴恩达与 LangChain 创始人 Harrison Chase 的对谈：AI Agent 不只是提升写代码速度，更会把瓶颈推向产品管理、组织协作、企业流程和数据架构。</p> </blockquote>
技术要点：</strong></p>

编程智能体能力快速迭代，吴恩达从主要使用 Claude Code 扩展到混用 OpenAI Codex、Gemini CLI、OpenCode 等工具。</li>
当代码实现速度提升 10 倍甚至 100 倍后，团队瓶颈会转移到需求定义、用户反馈、产品优先级、营销、法务、设计和合规等环节。</li>
未来软件团队可能更小、更快，由 1–10 人高上下文、高授权、技术能力强的通才组成，并借助 AI 覆盖产品、文案、条款初稿等跨职能工作。</li>
Agent 开发被类比为“乐高积木”：RAG、Agent 框架、评估、Guardrails、UI、认证、数据库等模块越丰富，开发者越需要掌握组合能力和最新上下文。</li>
企业采用 AI 不能只做单点自动化；更大的价值来自自上而下重构业务流程，例如把贷款审批从“节省一小时人工”重构成“10 分钟获批”的新产品。</li>
吴恩达提醒企业警惕模型和工具供应商锁定，强调供应商中立观测工具、开放权重模型和短周期选择权的重要性。</li>
Agent 真正落地依赖 AI-ready / agent-ready 数据架构，需要处理文本、PDF、图片、音频、视频等非结构化数据，并重构权限、治理和可观测性。</li> </ul>
应用场景：</strong></p>

适合关注 AI Agent 落地、AI 编程团队组织、企业 AI 转型和数据架构重构的技术与产品负责人阅读。</p> </blockquote>
原文链接：</strong> 📌 保存链接</a></p>

2026-06-16</h2>
谷歌首席工程师：二十年自然生长出来的软件工程生态，快被大模型 10 倍提速撑爆</a></h3>
来源：</strong> InfoQ 时间：</strong> 2026-06-16</p>
核心内容：</strong></p>

Google 首席软件工程师 Adam Bender 认为，AI 让代码产出提速 10 倍后，编译、测试、审查、版本控制和组织文化都会承压；赢家不是写得最快的团队，而是基本功最稳的团队。</p> </blockquote>
技术要点：</strong></p>

提出“软件生态学”：开发者环境是由工具、流程、组织结构、文化和激励共同构成的社会技术系统，AI 会放大整个系统的既有优劣。</li>
Google 的单体仓库、主干开发、统一构建、全球测试平台和代码审查文化共同形成“共享命运”，使大规模自动化变更成为可能，但这种能力依赖完整生态协同。</li>
AI 带来的不是单纯“工程效率 10 倍”，而是代码量、构建次数、测试资源、代码审查压力、token 成本、版本控制吞吐和发布风险的系统性放大。</li>
文章强调未来需要重新设计验证策略、集成测试、隔离机制、内部 API 治理、回滚策略、token 预算和 agent 工作流，避免“人人都是构建者”变成“人人都要维护混乱”。</li>
AI 是放大器而不是方向：扎实的工程基本功、决策文化、技术战略、安全、可靠性和代码健康度，决定放大后得到的是生产力还是混乱。</li> </ul>
应用场景：</strong></p>

适合技术负责人、平台工程、DevEx 和研发管理团队用来评估 AI 编程规模化后开发者生态的瓶颈与治理重点。</p> </blockquote>
原文链接：</strong> 📌 保存链接</a></p>

仅一行代码，Fable 5 复活了！</a></h3>
来源：</strong> ImportNew（转自：新智元）时间：</strong> 2026-06-15</p>
核心内容：</strong></p>

文章围绕 Claude Fable 5 下线与“复活”传闻，讨论系统提示词对模型人格、审美和工具行为的影响，以及高能力模型在安全护栏、越狱与治理上的风险张力。</p> </blockquote>
技术要点：</strong></p>

文章称开发者 Jamieson O’Reilly 使用泄露的 Fable 5 系统提示词，将其注入现役 Opus 4.8，尝试复现“轻量版 Fable 5”的行为风格。</li>
实验变量是系统提示词：同一模型、同一上下文、同一任务（制作现代苹果风网页），注入 Fable 5 prompt 后输出在品牌格调、文案语气、板块结构和整体审美上出现明显差异。</li>
泄露 prompt 文件据称包含约 12 万字符、1585 行、72 个命名章节，以及 18 个工具 JSON 定义，说明系统级 prompt 不只是“说明书”，也可能深度塑造工具边界、人格与任务执行节奏。</li>
文章提到使用 `claude --dangerously-skip-permissions --system-prompt-file CLAUDE-FABLE-5.md</code> 这类高危方式注入系统提示词；该参数会跳过权限确认，不适合安全生产环境。</li>`
`关于 Fable 5 下线，文章引用外媒爆料称亚马逊团队通过精心设计 prompt 绕过安全护栏并获取网络攻击相关敏感信息，随后政府介入要求 Anthropic 修复或下架模型。</li>`
`争议焦点是能力与安全的矛盾：如果高能力模型只靠护栏限制危险能力，护栏被绕过就可能暴露底层能力；越接近 ASI，提示词、系统护栏和访问控制的脆弱性越值得关注。</li>`
`文章也呈现了 Anthropic 的反驳角度：类似越狱方式可能在其他公开模型上复现，事件是否属于特定模型风险仍存在争议。</li> </ul> 应用场景：</strong></p>`适合关注系统提示词工程、AI Agent 安全、模型越狱、权限控制和高能力模型治理的开发者与安全研究者参考。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> Gemma 4 12B 开发者指南｜借助无编码器架构轻松构建本地多模态智能体</a></h3> 来源：</strong> 谷歌开发者 / Google 时间：</strong> 2026-06-15</p> 核心内容：</strong></p> Google 介绍 Gemma 4 12B：统一无编码器的 12B 稠密多模态模型，可在本地设备运行视觉、音频、文本和智能体工作流，降低多模态延迟并简化微调部署。</p> </blockquote> 技术要点：</strong></p> Gemma 4 12B 采用统一 encoder-free 多模态架构，绕过传统多阶段视觉/音频编码器，让多模态数据直接进入 LLM 主干网络，从而降低交互延迟和内存碎片。</li> 模型是 Gemma 家族首款支持音频输入的中型模型，可原生处理音频、视觉和文本，具备 ASR、agentic reasoning、diarization、视频理解和编码等能力。</li> 视觉侧使用 3500 万参数视觉嵌入器替代 27 层视觉 Transformer，将 48x48 像素块经单次矩阵乘法投影到 LLM hidden dimension，并用因式分解坐标查找注入空间位置信息。</li> 音频侧移除独立 Conformer 编码器，将 16 kHz 原始音频切成 40ms 帧，每帧 640 个浮点数，再线性投影到 LLM 输入空间。</li> 统一权重带来微调优势：视觉、音频和文本共享模型权重，LoRA 或全量微调可在一次传递中更新整个多模态 token 循环，支持 Hugging Face、Unsloth 等框架。</li> 本地运行门槛较低，可在 16GB 独显 VRAM 或统一内存笔记本上运行，并提供多 Token 预测（MTP）模型以提升本地推理速度。</li> 文章展示了用 llama.cpp + OpenCode + gemma-skills 在本地构建 Gradio 图像处理应用，以及用 1 FPS 视频帧、音频和提示分析 Google I/O 片段的多模态理解能力。</li> 设备端部署由 LiteRT-LM 支撑：Google AI Edge Gallery 扩展到 macOS，支持 Apple Silicon GPU 离线运行；litert-lm serve</code> 可将模型作为本地 OpenAI-compatible API server，支持 Continue、Aider、OpenClaw、Hermes、OpenCode 等工具接入。</li> 生态入口覆盖 LM Studio、Ollama、Google AI Edge Gallery/Eloquent、LiteRT-LM CLI、Hugging Face、Kaggle、llama.cpp、MLX、SGLang、vLLM、Unsloth、Google Cloud Model Garden、Cloud Run 和 GKE。</li> </ul> 应用场景：</strong></p> 适合希望在本地设备构建语音、视觉、视频理解和工具调用型多模态智能体的开发者与团队。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> AI 不缺智商缺纪律：我的 Harness 工程化实践</a></h3> 来源：</strong> 阿里云开发者时间：</strong> 2026-06-16</p> 核心内容：</strong></p> 作者复盘两个月 AI Coding harness 实践，认为瓶颈正从模型智商转向流程工程：模型供给能力，harness 通过规则外置、状态持久化、门禁阻断来供给纪律与稳定性。</p> </blockquote> 技术要点：</strong></p> Harness 被定义为把“AI 该怎么干活”固化成可执行、可约束、可评测的工程框架，不是继续堆 prompt；它针对工序随机、上下文污染、坑反复踩等 AI Coding 痛点。</li> 文章提出三层/多层加载思路：常驻入口层 CLAUDE.md</code>/CLAUDE.local.md</code> 保持极小上下文，原子规则层沉淀单一职责规则，按需上下文层只在阶段触发时加载模板、证据链、TDD/ATDD 等深内容。</li> 角色 Agent 层将主会话降级为“薄控制器”：dispatcher 只读状态做路由，orchestrator 做合成确认，requirement-analyst/tech-architect/quality-guardian 分别评审，developer/verifier/deployer/tester 分工执行。</li> 稳定性依赖确定性基础设施：G1–G8 门禁用 Python/eval 式硬校验产物、编译、单测和接口证据；hook 在运行时拦截越权写状态、危险命令等行为，默认 fail-closed。</li> 作者比较了 Workflow、Agent Team 与 dispatcher 状态机 + 文件交接：前者适合计算平面，Team 适合松散协作，文件交接更适合有状态工序链、人工门禁和跨天续跑。</li> 评测平台将 harness 本身当作被测对象，用确定性 Python 评分而非 LLM 评委，从流程完整性、产物质量、代码正确性、效率、安全合规、迭代能力、接口验收 7 个维度评估流程质量。</li> 关键经验包括：上下文是预算不是草稿纸；失败必须响亮不能静默兜底；给子 agent 精确文件清单；规则要从一次事故进化成可复用门禁，而非继续塞进大 prompt。</li> </ul> 应用场景：</strong></p> 适合正在搭建 AI Coding 工程化流程、Agent 编排、评测平台和企业级研发门禁的团队参考。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 读完 Agent Loop 工程手册，我有 8 个还没想明白的问题</a></h3> 来源：</strong> 腾讯云开发者 / 微信公众号时间：</strong> 2026-06-16</p> 核心内容：</strong></p> 作者二手解读 Agent Loop 工程手册，强调从“写 Prompt”转向“设计循环、停止条件、动态上下文和失败反馈”，并结合 SELF Protocol 反思 Agent 治理层仍未解决的问题。</p> </blockquote> 技术要点：</strong></p> Agent Loop 的核心是让 AI 围绕目标、护栏和可验证停止条件自动循环，而不是依赖人工逐句编写 Prompt。</li> 手册拆解了 Automations、Worktrees、Skills、Plugins/Connectors、Sub-agents、Memory、Guardrails 等组件，用于支撑自动化执行、隔离并行、工具连接、协作验收、记忆和资源约束。</li> 文章重点总结 4 个设计法：先定义 Stopping Condition；让 Context 根据失败日志、文件树和调用记录动态组装；把失败当作下一轮输入；用顺序流水线、协调者-工作者、扇出合并、生成-验证、共享状态、辩论对抗等拓扑组织多 Agent 协作。</li> 作者用 Agent Loop 视角重新定位 SELF Protocol：它不是替代 Loop 框架，而是治理/审查层，补强“不胡说、不失忆、不污染记忆、不重复踩坑”等认知护栏。</li> 文章也指出若干未解问题：技能沉淀仍可能重复失败，同模型验收存在共同盲区，红线触发和记忆分层仍不稳定，Agent Loop 的工程化治理还需要更可靠的评估和反馈机制。</li> </ul> 应用场景：</strong></p> 适合正在把 AI 从聊天助手升级为可执行 Agent 工作流的开发者，用于设计循环、验收、记忆和治理机制。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-06-15</h2> 最短一年内，模型会吞噬Harness？ Google AI Studio负责人：窄域超智能将率先在编程、数学、金融、科学等“可验证性“领域实现</a></h3> 来源：</strong> 51CTO技术栈 | 作者：玉澄时间：</strong> 2026-06-15</p> 核心内容：</strong></p> Google AI Studio负责人预测，窄域超智能（Narrow Superintelligence）将在可验证性领域率先实现，时间线可能短至一年内。重点领域包括编程、数学、金融、科学等具有明确正确/错误标准的学科。</p> </blockquote> 技术要点：</strong></p> 窄域超智能定义</strong>：在特定领域达到或超越人类水平的AI系统</li> 可验证性领域优先</strong>：编程、数学、金融、科学等领域因有明确的正确/错误标准，更容易实现突破</li> 时间预测</strong>：最短一年内，模型可能在某些特定领域展现出超智能水平</li> 模型vs工具</strong>：提到模型可能会“吞噬Harness“（可能指某个工具或框架），暗示AI模型将集成或取代现有工具</li> 发展路径</strong>：窄域超智能是通向通用人工智能（AGI）的重要里程碑</li> </ul> 应用场景：</strong></p> 软件工程师、数据科学家、金融分析师、科研人员应关注这些领域的AI突破，理解AI如何加速各自领域的工作流程和决策过程。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-06-08</h2> 黄仁勋劝年轻人去看电工、水管工、技工等职业，AI时代最不缺程序员</a></h3> 来源：</strong> 纪中展讲决策（虎嗅转载） | 作者：纪中展时间：</strong> 2026-06-08</p> 核心内容：</strong></p> 黄仁勋在卡内基梅隆大学毕业典礼上对年轻人说：电工、水管工、钢铁工人、技师、建筑工人，这是你们的时代。AI不只是在创造一个新的计算产业，而是在创造一个新的工业时代。真正的机会不在AI的前台（大模型、应用、智能体），而在支撑它的后台（电力、数据中心、芯片工厂、冷却系统、施工能力）。</p> </blockquote> 技术要点：</strong></p> ✅ Browser直接成功抓取微信完整内容</li> 前台vs后台</strong>：大多数人看到AI的前台（大模型、应用、智能体、机器人），黄仁勋看到AI的后台（电力、数据中心、芯片工厂、冷却系统、施工能力、设备安装、运维体系）</li> AI让世界重新变重</strong>：越强的AI需要越强算力，越强算力需要越多数据中心，越多数据中心需要越多的电、土地、建筑、冷却和设备；智能越虚拟，脚下踩的现实越沉重</li> 基础设施投资规模</strong>：2026年美国大型科技公司AI基础设施资本开支约7000亿美元，到本十年末全球数据中心热潮投资规模或近7万亿美元</li> 真正的瓶颈是人</strong>：Randstad报告显示技术工种需求增长27%，建筑岗位涨30%，焊接涨25%，电工岗位涨20%，机器人技师需求涨一倍多；卡住全球AI建设的不是缺芯片，而是缺技工</li> 企业家三个问题</strong>：企业核心能力是前台还是后台？AI进入行业后什么能力会被重新定价？是在追逐热词还是建设“把复杂事情做成”的能力？</li> 判断力训练</strong>：不要只看时代最耀眼的部分，要看它的底座；移动互联网底座是智能手机/4G/支付/物流，电商底座是仓储/快递/供应链，AI底座是芯片/算力/电力/数据中心/能源/工程/制造</li> 深层洞察</strong>：每一个时代的故事写在最响亮的词上，但真正的红利沉淀在很少被人提起的底座里</li> </ul> 应用场景：</strong></p> 职业规划者、企业家、投资者，理解AI时代的机会分布——不是在前台的编程和应用，而是在后台的基础设施建设、制造和技工领域。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 从Palantir到企业竞争，重新理解DRP的底层逻辑</a></h3> 来源：</strong> 中智咨询 | 作者：李智勇时间：</strong> 2026-06-08</p> 核心内容：</strong></p> 企业竞争已经从拼规模、资金、渠道转向拼资源实时协同能力。Palantir真正的厉害之处不是“数据”而是“行动”——把场景目标、规则体系、资源关系与实时行动放进同一个动态运行系统。DRP（Digital Resource Platform）正是企业级的“实时资源操作系统”。</p> </blockquote> 技术要点：</strong></p> ✅ Browser直接成功抓取微信完整内容</li> 企业竞争范式转移</strong>：过去拼规模/资金/渠道，现在拼资源实时协同能力；监管进入“全面穿透式监管时代”（全链路、全级次、全要素、动态实时）</li> 新商业时代命题</strong>：不再是单纯“经营效率问题”，而是“经营与监管如何在同一个系统中协同运行”</li> Palantir的本质</strong>：不是“大数据公司”，而是第一次把场景目标、规则体系、资源关系与实时行动放进同一个动态运行系统</li> 记录系统vs行动系统</strong>：传统ERP/CRM/BI是“记录系统”（System of Record），终点是“看”；Palantir是“行动系统”（System of Action），理解场景/目标/规则/资源关系，推演出下一步行动</li> 规则比数据更重要</strong>：数据只能告诉你“发生了什么”，规则决定的才是“接下来应该怎么办”。相同数据在不同场景规则下触发完全不同的系统动作</li> 三个场景示例</strong>：效率优先（自动放行预算、快速审批）、监管优先（穿透关联、识别异常、触发预警）、平衡优先（调整资源倾斜、限制预算）</li> 现代战争启示</strong>：现代战争拼的是感知能力、协同能力、决策速度和资源调度能力；瞬间完成“情报更新→风险判断→权限校验→资源匹配→行动推演→指令协同”</li> DRP定义</strong>：Digital Resource Platform（数字资源平台），企业级的“实时资源操作系统”，运行全新闭环：场景→规则→关系→资源→行动→反馈</li> 未来竞争优势</strong>：不是“有没有AI”，而是是否拥有一个可被AI理解与驱动的资源运行体系</li> </ul> 应用场景：</strong></p> 企业数字化决策者、技术架构师、关注资源协同与监管穿透的管理者，理解从“记录系统”到“行动系统”的范式转移，以及DRP作为实时资源操作系统的价值。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 本体论不是银弹：当90%的公司，把Palantir学成了“高级外包“</a></h3> 来源：</strong> 中智凯灵（原文CSDN转载）时间：</strong> 2026-06-08</p> 核心内容：</strong></p> 没有本体论作为语义骨架，LLM只是在数据沼泽中打转。Palantir连续亏损19年，市值突破4000亿美元，其真正的护城河不是技术本身，而是将业务认知产品化的能力。90%的模仿者只复制了FDE的形，却丢失了本体论的魂，最终沦为高成本服务商。</p> </blockquote> 技术要点：</strong></p> ✅ 通过searxng搜索找到CSDN转载源并成功抓取完整内容</li> 本体论工程化</strong>：将企业运营中的人、物、地点、事件、订单等业务实体抽取出来，构建跨部门、跨系统的统一语义层</li> 范式转移</strong>：传统企业数字化遵循“系统先于数据“，Palantir彻底反转——数据成为一等公民，应用只是数据的投影</li> 三大工程突破</strong>：动态知识图谱引擎（支持多模态数据关联）、Git for Data版本化架构（字段级时间回溯）、细粒度安全隔离体系</li> 与大模型化学反应</strong>：本体论为LLM提供高质量上下文，LLM反向加速本体构建，推理准确率提升3-5倍</li> FDE幻觉</strong>：90%模仿者掉入服务陷阱——将定制等同于价值、混淆数据集成与语义建模、误判问题复杂度、忽视组织变革成本</li> 标杆案例</strong>：空客A350供应链25倍ROI（中断响应从72小时缩短至4小时）、松下电池工厂AI Copilot（培训周期从3-6月压缩至3周）、医疗分诊优化（效率提升10-15倍）</li> 中国本土化方向</strong>：垂直行业本体论、轻量级FDE模式、数据飞轮驱动</li> AI原生操作系统战争</strong>：Palantir以本体论为内核争夺认知资源管理标准，Databricks/Microsoft/中国玩家各有布局</li> </ul> 应用场景：</strong></p> 企业AI落地决策者、技术架构师、关注数字化转型的管理者，理解从工具售卖到结果交付的本质差异，以及如何构建适配本土市场的本体论变体。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-06-02</h2> 鹅厂面试官：“你怎么看 Harness Engineering？” 我：“就是给大模型套缰绳” 他拍桌：终于有人说明白了</a></h3> 来源：</strong> 小林coding 时间：</strong> 2026-06-02</p> 核心内容：</strong></p> 通过腾讯面试场景，把 Harness Engineering 形象解释为“给大模型套缰绳”——核心哲学八个字：人类掌舵，智能体执行。LangChain 仅改 Harness，Terminal Bench 排名从第 30 跃升至第 5。真正的挑战不再是让 AI 写得更好，而是怎么驾驭它稳定、可靠、不失控地工作。</p> </blockquote> 技术要点：</strong></p> ✅ 通过searxng搜索找到菜鸟教程完整转载并成功抓取</li> 定义</strong>：围绕 AI 智能体设计和构建约束机制、反馈回路、工作流控制和持续改进循环的系统工程实践</li> 核心哲学</strong>：Human Steer, Agent Execute（人类掌舵，智能体执行）</li> 起源</strong>：2026年2月 Mitchell Hashimoto 首次提出，OpenAI 在百万行代码实验报告中正式采用</li> 三次范式跃迁</strong>：Prompt Engineering（怎么说）→ Context Engineering（给什么信息）→ Harness Engineering（怎么可靠运行）</li> Agent 三大失败模式</strong>：试图一步到位（One-shotting）、过早宣布胜利、过早标记功能完成</li> 四大护栏</strong>：上下文工程（新员工手册AGENTS.md）、架构约束（分层依赖+Linter）、反馈循环（Agent审Agent）、熵管理（垃圾回收）</li> 六大行业共识</strong>：瓶颈在基础设施不在模型、文档必须是活的反馈循环、思考与执行分离、上下文不是越多越好、约束必须自动化、工程师角色在转变</li> 实践案例</strong>：OpenAI 5个月100万行代码0人工、LangChain 52.8%→66.5%排名跃升、Ghostty项目AGENTS.md每行对应一个失败案例</li> 工程师角色转变</strong>：从代码编写者变成环境的建筑师，最大的工程挑战是设计让 Agent 可靠工作的控制系统</li> </ul> 应用场景：</strong></p> 准备大厂 AI 工程师/Agent 系统面试、正在搭建生产级 Agent 平台、希望从 Prompt 调参跨入“系统设计”视角的开发者与架构师。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-05-20</h2> 让Skill自己训练自己：8阶段Loop、3层评测、5维AND门控，从此实现自进化</a></h3> 来源：</strong> 腾讯云开发者 | 作者：张思宇时间：</strong> 2026-05-19</p> 核心内容：</strong></p> 作者开发了一个名为 skill-evolver 的工具，让 Skill 能够像神经网络参数一样被训练——通过8阶段Loop、3层评测、5维AND门控机制，实现自我迭代、自我评测、自我回归，19轮自进化实现100%通过率。</p> </blockquote> 技术要点：</strong></p> 核心思想</strong>：Skill 不应该是手工打磨的工艺品，而应该是一个可以被训练、被回滚、被选优的对象；灵感来源于 Karpathy 的 autoresearch、Stanford 的 Meta-Harness、Anthropic 的 skill-creator</li> 8阶段Loop框架</strong>：Setup → Review → Ideate → Modify → Commit → Verify → Gate → Log → Loop，每轮只做一个原子化改动</li> 3层评测体系</strong>：L1 快速门卫（秒级，结构检查）→ L2 Dev Eval（分钟级，全量评测）→ L3 Strict Eval（10分钟，holdout集防过拟合）</li> 5维AND门控</strong>：质量提升？成本不涨？安全无退？回归守卫？原子性？全部YES才保留，任何一个NO就git revert</li> Trace驱动诊断</strong>：保存完整执行记录，下一轮让 proposer 自己去看 trace，不给压缩摘要（效果+44%）</li> 分层Mutation</strong>：Layer 1 改触发关键词 → Layer 2 改 SKILL.md 正文 → Layer 3 改辅助脚本，不准跨层</li> Meta-evolution自证</strong>：工具优化自己，19轮全keep、零回滚，主文件从1411行拆成13个小文件，测试用例从17扩到31个</li> </ul> 应用场景：</strong></p> Skill 开发者、AI 工程师、Claude Code 用户，提升 Skill 质量、自动化测试和迭代、真实业务场景优化（如客服问答 skill 召回率从86%提升到98.67%）。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> —## 2026-05-19</p> The last six months in LLMs in five minutes</a></h3> 来源：</strong> Simon Willison’s Blog 时间：</strong> 2026-05-19</p> 核心内容：</strong></p> Simon Willison 在 PyCon US 2026 的5分钟闪电演讲，总结了过去六个月 LLM 的发展，特别是2025年11月的转折点：编码代理从“经常能用“变为“主要能用“，OpenClaw（个人AI助手）爆发，开源模型（Gemma 4、GLM-5.1）超出预期。</p> </blockquote> 技术要点：</strong></p> 11月转折点</strong>：最佳模型宝座频繁更迭（Claude Sonnet 4.5 → GPT-5.1 → Gemini 3 → GPT-5.1 Codex Max → Claude Opus 4.5）</li> 编码代理质变</strong>：通过 RLVR（Reinforcement Learning from Verifiable Rewards）训练，编码代理从“经常能用“变为“主要能用“，可作为日常工具完成实际工作</li> OpenClaw 爆发</strong>：11月底首次提交，2月更名后引爆全球，Mac Mini 因作为“Claw 的完美鱼缸“而脱销</li> Claw 隐喻</strong>：被称为“数字宠物“，被比作蜘蛛侠2中的 Doc Ock（AI驱动的机械爪，除非抑制芯片损坏否则安全）</li> 开源模型突破</strong>：Google Gemma 4 系列（美国公司最强开源权重）、GLM-5.1（1.5TB 开源模型，虽然硬件要求高但效果显著）</li> 视觉生成测试</strong>：使用“鹈鹕骑自行车“作为模型能力测试（难画、无训练数据、荒谬任务），GLM-5.1 表现出色（包括动画“弗吉尼亚负鼠在电动滑板车上巡航“）</li> </ul> 应用场景：</strong></p> 开发者和AI研究者关注 LLM 快速演进趋势，个人用户可尝试本地运行的开放权重模型，企业可考虑部署编码代理提升生产力。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-05-12</h2> AI梦之队放大招！全新实时交互模型：边听边看边思考，还能干活；语音响应速度仅需0.4秒！双模型架构，重构人机协作范式</a></h3> 来源：</strong> 51CTO技术栈 | 作者：玉澄 | 发布时间：2026年5月12日</p> 核心内容：</strong></p> Thinking Machines Lab（TML，团队约2/3来自OpenAI，含Mira Murati、John Schulman、翁荔等大牛）发布全新实时交互模型 TML-Interaction-Small，能边听边看边思考，语音响应仅需0.4秒，并支持工具调用和实时UI生成，重构传统回合制AI交互范式。</p> </blockquote> 技术要点：</strong></p> 双脑协同架构</strong>：交互模型（实时陪聊、保持时间感知）+ 后台模型（处理复杂推理、工具调用、长时任务），快慢结合，既秒回又能深度思考</li> 200ms 微轮次机制（Time-aligned micro-turns）</strong>：持续交错处理200ms输入和生成200ms输出。人类对话停顿超250ms会感知卡顿，所以200ms是临界点</li> 预测式接话能力</strong>：模型可以预测用户何时结束、提前准备回应、在语义未完时理解意图——更接近人类对话节奏</li> 主动介入能力</strong>：通过摄像头主动提醒坐姿，发现错误想法主动纠正，可作为同声传译并调节情绪语气</li> 时间感知</strong>：对时间流逝有感知能力，可在指定时间执行操作（如每4秒提醒呼吸）</li> 后台并行</strong>：一边聊天一边在后台搜网页、查资料、生成UI，结果实时呈现</li> 模型规模</strong>：276亿参数MoE，120亿激活参数</li> 新基准发明</strong>：FD-bench/Audio MultiChallenge（传统）+ TimeSpeak/CueSpeak（主动音频）+ RepCount-A/ProactiveVideoQA/Charades（视觉主动性）</li> 更人性化的安全策略</strong>：用口语化、自然方式拒绝或转向健康话题，情商在线</li> 设计哲学</strong>：交互能力应当成为模型的「原生能力」，而非外接对话管理组件——「未来每一个AI系统都会有类似交互模型的东西作为面向用户的外部层」</li> </ul> 应用场景：</strong></p> 智能机器人、健身实时指导、教育辅助、头脑风暴搭子、日常生活助手——AI从「离线留言式回复工具」进化为「真正的协作伙伴」。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-05-08</h2> 停止编码的那天，就是失去架构判断力的开始：一位 30 年架构师的 AI 生存指南</a></h3> 来源：</strong> InfoQ | 作者：Tina | 发布时间：2026年5月8日</p> 核心内容：</strong></p> 在AI Coding飞速发展的当下，微软最有价值专家(MVP)、拥有近30年编码经验的架构师Dennis Doomen分享了他的观点：如果不深入代码，就无法做出优秀的架构决策。他探讨了在AI可以生成代码的时代，如何保持对代码质量的掌控。</p> </blockquote> 技术要点：</strong></p> 编码与架构的关系</strong>：作为架构负责人，同时保持动手实践是团队中唯一有效的软件开发方式。如果停止编码，就会逐渐失去对系统复杂性的判断力</li> 系统复杂性管理</strong>：软件工程的核心是在已有系统与不断增长的复杂性之间维持平衡。如果对过去的决策缺乏理解却机械遵循，会不断累积复杂性，时间会放大这一问题</li> AI时代的代码掌控</strong>：即便未来我们可能不再需要编写代码，现阶段仍然需要对AI生成的结果进行接管和维护</li> 文档重于实现</strong>：无论是提交记录还是代码评审说明，都应尽量记录决策意图，而不仅是技术细节</li> 动手型架构师理念</strong>：Dennis自称“动手型架构师“，所有分享都源于一线经验。52岁的他仍坚持编码，与开发者一起编写生产代码</li> 架构的迭代本质</strong>：从零开始设计系统时，架构本身包含假设，需要在实践中验证和调整。过程本质是持续迭代：设计→实现→反思→再调整，与敏捷开发一致</li> 复杂性的权衡</strong>：应将模块视为边界，在边界内保持一致性，优先简化模块本身，而非为了全局一致牺牲可维护性</li> 对DRY原则的务实态度</strong>：在某些情况下，有意识地复制代码以降低耦合，但必须是经过权衡的决策，而非盲目复制</li> 设计模式的过度使用问题</strong>：许多10-15年经验的开发者掌握设计模式后往往过度依赖，常为未来可能性设计抽象而非满足现实需求</li> AI辅助开发实践</strong>：Dennis开发.NET开源HTTP Mock库时，将GitHub issue分配给Copilot，AI生成了高质量的完整项目。他采用人机协作方式，部分功能由AI生成，部分手动完成</li> 测试优先的AI审查</strong>：重点审查测试，确保其准确反映预期行为。让AI生成额外测试用例后，逐一审查确认符合编码模式</li> </ul> 核心观点摘录：</strong></p> 作为架构负责人，同时仍保持动手实践，这是团队中唯一有效的软件开发方式</li> 即便未来我们可能不再需要编写代码，现阶段仍然需要对AI生成的结果进行接管和维护</li> 无论是提交记录还是代码评审说明，都应尽量记录决策意图，而不仅是技术细节</li> </ol> 应用场景：</strong></p> 适用于软件架构师、技术管理者和资深开发者，在AI时代保持技术判断力和核心竞争力，平衡AI辅助开发与代码质量掌控。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-04-29</h2> 用 Claude Code Skill 治理文档漂移：FlashDuty 的 AI 文档审查实践</a></h3> 来源：</strong> Flashcat 技术博客时间：</strong> 2026-04-29</p> 核心内容：</strong></p> 介绍 FlashDuty 使用 Claude Code Skill 治理文档漂移的实践经验，包括为什么文档总是跟不上、他们如何构建 AI 文档审查系统、发现的问题及未来计划。</p> </blockquote> 技术要点：</strong></p> 文档漂移问题</strong>：FlashDuty 没有专职产品经理，工程师身兼数职导致文档更新滞后，影响 AI 客服回答质量</li> Claude Code Skill 解决方案</strong>：核心设计思路：YAML 映射文件关联文档页面和源码路径</li> 两种模式： Diff 模式：检查最近代码变更与文档的一致性</li> Audit 模式：遍历前端代码盘点功能，检查文档覆盖和准确性</li> </ul> </li> </ul> </li> 发现成果</strong>：第一次运行后输出 20 个 PR，新增 9000 多行文档，覆盖 370 多个文件</li> 经验总结</strong>：从前端入手、用产品经理视角判断、只检查可机械验证的事实、生成完整内容而非占位符</li> 下一步计划</strong>：接入 CI 自动检测、扩展到 API 文档</li> </ul> 应用场景：</strong></p> 适用于无专职文档维护人员的团队，通过 AI 自动化检查和生成文档，提升产品文档质量和开发效率。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-04-10</h2> 大模型如何低成本适配特定领域？「知识编辑」让大模型记住新知识，不用全参数微调</a></h3> 来源：</strong> 机器之心时间：</strong> 2026-04-09</p> 核心内容：</strong></p> 探讨大模型领域适配中「知识编辑」技术路线，对比全参数微调、RAG、知识编辑三种方案，认为知识编辑兼具低成本（仅需少量参数修改）和效果好（直接将知识写入模型参数）两大优势，是未来中小企业落地大模型的重要方向。</p> </blockquote> 技术要点：</strong></p> 三种主流方案对比</strong></p> 全参数微调：效果最好但成本极高，中小企业负担不起</li> RAG：低成本但推理延迟高、上下文有限、多跳推理能力差</li> 知识编辑：仅修改少量参数，将新知识写入模型，推理效率与原生模型一致</li> </ul> </li> 知识编辑核心挑战</strong></p> 定位：准确定位需要修改的参数，避免影响其他无关知识</li> 泛化：编辑后不伤害模型通用能力，保持泛化性能</li> 连贯：编辑多知识点后不发生冲突，保持模型整体连贯性</li> </ul> </li> 最新研究进展</strong></p> Meta AI 提出的 MEND 框架：通过超网络生成参数更新增量，不直接训练原模型参数</li> 北京大学 EASYEDIT 框架：统一多种编辑任务，支持开放域编辑，公开评测基准</li> 最新趋势：从「基于增量」向「直接定位参数」发展，定位越来越精准</li> </ul> </li> 产业落地趋势</strong></p> 垂直领域知识更新频繁（比如法律新规、医疗新药），知识编辑比全微调更灵活</li> 推理成本与基础模型一致，适合边缘/端侧部署</li> 创业公司机会：专注特定垂直领域做深度知识编辑优化，比通用大模型更精准</li> </ul> </li> </ul> 应用场景：</strong></p> 中小企业大模型落地、垂直领域知识更新、端侧部署大模型应用，适合需要平衡成本与效果的场景。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-04-09</h2> 从决策、执行到记忆复利：gstack + Superpowers + CE 完整实战工作流</a></h3> 来源：</strong> AI架构之道时间：</strong> 2026-04-08</p> 核心内容：</strong></p> 文章介绍了Claude Code生态中三款流行工具gstack、Superpowers、Compound Engineering（CE）的三层互补体系：gstack做决策把关，Superpowers做流程标准化，CE做知识复利沉淀，三者结合覆盖AI开发全流程，实现持续高效的AI辅助开发。</p> </blockquote> 技术要点：</strong></p> 架构背景</strong> - 匹配Anthropic官方Harness架构四大关键角色：Planner（规划）、Coding Agent（执行）、Evaluator（评估）、Cross Session Bridge（跨会话桥接），核心结论：生成与评估必须分离</li> gstack（决策与测试层）</strong> - 定位顶层控制工具，提供双评审机制（产品视角/架构视角），并支持通过/qa</code>命令启动真实浏览器端端到端测试，而非仅静态代码审查；实测能做到60天产出60万行生产级代码含35%测试</li> Superpowers（标准化流程层）</strong> - 以138.8K Star成为Claude Code标配，将对话升级为brainstorm → plan → execute → review</code>标准工作流；但对比CE存在三大硬伤：规划无历史支撑、评审维度单一、无知识积累无法形成复利</li> Compound Engineering（知识复利核心层）</strong> - 在Superpowers流程基础上升级，新增/ce:compound</code>核心环节，开发完成后自动启动5大子Agent完成结构化知识沉淀：上下文分析、方案提取、关联文档查找、预防策略制定、自动分类存储，存入docs/solutions/</code>形成永续项目记忆</li> 三层完整工作流</strong> - 决策层(gstack产品+技术评审) → 规划层(CE基于历史深度规划) → 执行层(CE单功能增量开发) → 评审层(CE专项评审 + gstack浏览器测试) → 知识层(CE沉淀经验知识库)</li> 11步落地实操</strong> - 从需求确认、项目启动、双维度评审、方案脑暴、深度规划、增量执行、专项评审、真实测试、知识沉淀到版本交付，形成完整闭环</li> </ul> 应用场景：</strong></p> 使用Claude Code进行AI辅助开发的团队和个人，通过分层工具组合实现决策把关、流程规范和知识复利，长期开发中持续提升效率，避免重复踩坑。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-04-07</h2> What is the best LLM for translation? A comparison of top AI translation models</a></h3> 来源：</strong> Lokalise Blog 时间：</strong> 2026-03-16</p> 核心内容：</strong></p> Lokalise 通过盲测对比发现，没有通用的最佳翻译 LLM，应该根据任务类型选择模型：Claude 适合高语境营销翻译，GPT-4o/5 适合技术文档和代码本地化，Gemini 适合长上下文多文件一致性，DeepSeek 适合高容量低成本批量翻译。</p> </blockquote> 技术要点：</strong></p> 实验结论</strong> - LLM 在所有测试语言对中表现均优于传统机器翻译（DeepL/Google Translate/Microsoft Translator），“良好“率达到 55.7% - 80%；WMT25 研究也证实顶级翻译系统越来越依赖 LLM 或混合方法</li> 模型选择策略</strong> - Claude 3.5/4 擅长营销翻译，对语气、习语、品牌声音把控更好；GPT-4o/5 在技术文档和代码本地化中更可靠，能很好保留变量、占位符和格式；Gemini 长上下文窗口（可达 2M tokens）适合完整文档集、仓库翻译；DeepSeek 定价模型适合高容量低风险批量翻译，成本效益最高</li> 生产自动化流程</strong> - Lokalise AI Orchestrator 实现动态模型路由，根据内容类型和任务自动选择最优模型；通过 Custom AI Profiles 维护术语和品牌语气一致性，RAG 连接已批准翻译记忆，AIQE 评分实现自动质量路由（高于 80 分自动批准，低于 80 分人工审核）</li> 核心优势</strong> - LLM 比传统 MT 更擅长上下文理解、文化细微差别处理、专业术语适应性，翻译一致性更好</li> </ul> 应用场景：</strong></p> 本地化团队、翻译服务提供者、需要建立自动化翻译流程的组织。根据任务特征动态选择模型比固定使用单一模型能获得更好质量和成本效益。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-04-03</h2> 还在写 PRD？AI 时代的产品经理，核心交付物变了</a></h3> 来源：</strong> 深思 SenseAI 时间：</strong> 2026-04-02</p> 核心内容：</strong></p> Braintrust 提出“Evals are the new PRD“——AI 时代产品经理的核心交付物从需求文档变为结构化评测。Eval 同时扮演产品规格、验收标准、路线图三重角色，通过飞轮循环（观察→分析→评测→改进）实现质量复利增长。</p> </blockquote> 技术要点：</strong></p> 核心论点</strong> - Braintrust 文章提出“Evals are the new PRD“，OpenAI 科学副总裁 Kevin Weil 确认“写 eval 是 AI 时代 PM 最重要的事“；传统 PRD 是为确定性世界设计的，而 AI 产品世界是非确定性的</li> 新旧循环对比</strong> - 传统：Problem→Spec→Design→Engineering→Ship（线性确定）；新循环：PM 用代码定义“好“是什么，团队通过 hillclimbing 反复迭代直到达标</li> Eval 的本质</strong> - AI 行为的单元测试，定义一组输入和预期输出，用算法或 AI 评审员打分；以食谱生成器为例，拆解为三个可衡量信号：格式正确性（AI 评审）、食材完整性（字符串匹配）、步骤简洁性（AI 评审校准）</li> Eval 飞轮四阶段</strong> - Observe（记录每次输入输出和失败）→Analyze（找失败模式）→Evaluate（把失败变成新 eval case）→Improve（针对 eval suite 做 hillclimbing）；线上数据持续回流到 eval suite 形成复利</li> 成熟度四阶梯</strong> - Stage 0 Vibes（手动抽查/直觉）→Stage 1 Test Sets（带通过/失败标准的测试集）→Stage 2 CI/CD（集成到流水线，自动拦截坏的发布）→Stage 3 Flywheel（线上失败自动变成测试用例，系统每周变好）</li> 三种评委</strong> - 算法评委（确定性检查，快且可靠）、AI 评委（模糊质量评估，需人类判断校准）、人类对齐的 AI 评委（深度主观评估，用人类标注教 AI 什么是好）</li> 常见坑</strong> - 试图衡量“通用智能“（应给产品写自己的考试）、eval 设计拉太多人（保持小团队）、只在上线时跑 eval（需持续跑）、Goodhart’s Law（优化分数而非真实结果，需与业务指标绑定校准）</li> PM 新节奏</strong> - 周一看线上 trace 标记 20 个不达标响应→周二提炼 5 个新 eval case→周三跑完整 suite 对比→周四数据决定发布→周五飞轮转快；线上失败→测试用例→驱动改进→新数据</li> 深层意义</strong> - AI 产品质量不是“做出来再说“而是“先定义好“；Eval 是 AI 产品的复利引擎和团队知识沉淀（500 条 case 的 eval suite 记录半年边界情况和决策）；PM 角色从“写文档的人“变成“定义质量的人“</li> </ul> 应用场景：</strong></p> AI 产品经理、AI 工程团队、希望建立 AI 产品质量体系的组织。从 spreadsheet 开始写第一个 eval，每次线上坏 case 加进 suite，几个月后 eval suite 将成为最有价值的资产。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-04-01</h2> 拆完了 Claude Code 4756 个源码文件，原来好用的产品都在做同一件事</a></h3> 来源：</strong> Petterp 时间：</strong> 2026-04-01</p> 核心内容：</strong></p> 通过分析泄露的 Claude Code 4756 个源码文件，揭示 AI 产品真正的竞争力不在于模型或 prompt，而在于给模型一套更好的“管法“。文章提炼 5 条核心原则：好行为必须写成制度、做事和验收必须分离、工具执行要有关卡、注意力是预算、让 AI 感知能力边界。</p> </blockquote> 技术要点：</strong></p> 源码泄露事件</strong> - 有人从 npm 包的 source map 文件还原出 4756 个源码文件，整个系统内部结构被摊开；大部分分析聚焦在 system prompt 和工具调用，但这只是“皮肤“</li> 原则一：好行为必须写成制度</strong> - Claude Code 的行为规范具体明确：不要加用户没要求的功能、不要过度抽象、不要瞎重构、不要乱加注释、不要做不必要的错误处理、遇到风险要停下来确认；“不要做什么“比“要做什么“更能决定产出质量</li> 原则二：做事的和验收的必须是两个角色</strong> - 源码确认至少 5 个独立 Agent，写代码的 Agent 和验证代码的 Agent 完全分开；验证 Agent 的核心指令是“想办法搞坏它“，强制要求每一项验证都必须有实际执行的操作和观察到的结果</li> 原则三：工具执行要有关卡</strong> - 完整治理链：找到工具定义→校验输入参数→预判操作风险→运行前置检查→做权限决策→真正执行→运行后置检查→处理可能的失败；局部环节有灵活性，但全局安全底线不可突破</li> 原则四：AI 的注意力是预算</strong> - system prompt 分成两段（基础规则可缓存 + 动态调整信息）、扩展能力按需加载、专门机制压缩历史对话；上下文是稀缺资源，塞进去的信息越多每条信息被关注的程度就越低</li> 原则五：让 AI 知道工具箱里有什么</strong> - Skill/Plugin/MCP 三套扩展机制不只是挂载到系统上，而是通过专门通道告诉 AI 有哪些新能力、什么场景该用、怎么用；AI 不需要猜自己能做什么，它被明确告知</li> 日常应用建议</strong> - 给 AI 加约束（“不要做什么”）、分阶段对话（调研/规划/执行/验证分成独立对话）、做之前先说计划、区分可逆和不可逆操作、一次对话只做一件事、长对话要主动刷新、给背景信息时做减法比做加法重要</li> </ul> 应用场景：</strong></p> AI 工具使用者、AI 产品设计者、希望提升 AI 协作质量的开发者。这 5 条原则不仅适用于 AI 产品工程，也适用于个人与 AI 的日常交互。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-03-31</h2> AI Agents Could Make Free Software Matter Again</a></h3> 来源：</strong> GJ London 时间：</strong> 2026-03-31</p> 核心内容：</strong></p> AI 编程代理正在重新定义软件自由的价值。作者通过 Sunsama 工作流定制经历说明：闭源 SaaS 阻碍用户自定义，而自由软件 + 代理让非技术用户也能行使“修改软件“的自由。核心洞察：代理是技术自由的代理执行者，让 Stallman 的“四大自由“从理论权利变成实际能力。</p> </blockquote> 技术要点：</strong></p> SaaS loophole</strong> - GPL 只在“分发“时触发源码共享义务，SaaS 通过网络服务规避此要求，导致自由软件运动边缘化</li> AGPL 的困境</strong> - 试图关闭 SaaS 漏洞，但被 Google 等大公司抵制；MongoDB/Redis/HashiCorp 等转向自有许可证</li> Sunsama 定制案例</strong> - 作者尝试用 AI 代理定制任务管理工作流，遭遇 6 层障碍：无官方 API、需存储真实密码、iOS Shortcut 无法自动化、依赖逆向工程、手动构建、基础设施自托管</li> 代理作为自由的执行者</strong> - 非技术用户可通过描述需求，让代理行使 Freedom 1（研究并修改软件），无需理解代码</li> 闭源 vs 自由的实际差异</strong> - 自由软件：代理读源码→理解数据模型→按需修改；闭源 SaaS：无源码、API 限制、只能等待厂商功能</li> 思想转变</strong> - 从“是否有专业能力定制“变为“是否有权限让代理定制“；四大自由从理论权利变为实际能力差异</li> 相关观点</strong> - Nawaz Dhandala (OneUptime)：AI 代理给开源带来“不可逾越的优势“；Protesilaos Stavrou：自由软件需解决“非技术用户如何行使自由“的问题</li> </ul> 应用场景：</strong></p> 使用 AI 编程代理（Claude Code/Cursor/Codex）的开发者、关心软件自主权的用户、受困于 SaaS 功能限制的团队。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> The Cognitive Dark Forest</a></h3> 来源：</strong> Ryan Lang 时间：</strong> 2026-03-31</p> 核心内容：</strong></p> AI 时代正在形成“认知黑暗森林“：集中化 AI 平台通过用户 prompt 收集意图信号，大公司以算力和资本快速吸收创新。公开分享从“收益>风险“变为“风险>收益“，开发者将回归私下创新。核心悖论：AI 公司依赖人类开放性训练模型，却会杀死这种开放性。</p> </blockquote> 技术要点：</strong></p> 2009 年的互联网</strong> - 开源分享文化：想法廉价、执行困难、世界充满机会；GitHub 公开代码、论坛交流、博客分享，互联网是“明亮的草地“</li> 黑暗森林理论</strong> - 刘慈欣《黑暗森林》：宇宙中暴露的文明会被消灭，隐藏是唯一生存策略；非恶意，而是博弈论的理性反应</li> 互联网 consolidation</strong> - 2026 年互联网已被大公司和政府 consolidate；机会空间收缩，未来黯淡，从“追求成功“变为“挣扎求生“</li> AI 改变执行成本</strong> - LLM 前：想法需要程序员（昂贵、缓慢、不可扩展）；LLM 后：整个项目可一键生成，执行变得廉价</li> 平台优势</strong> - 大公司拥有算力 + 模型 + 开发者数据；你的创新可被快速吸收复制，只需投入算力和资本</li> Prompt 即信号</strong> - 每个 prompt 都流向集中化 AI 平台，暴露意图；平台无需监视个人，只需统计聚类，就能提前知道“哪个想法有潜力“</li> 认知黑暗森林</strong> - 最危险的不是同行竞争者，而是森林本身（平台）；你的创新成为训练数据，差异化变成平台的中位数能力</li> 抵抗的悖论</strong> - 抵抗不会被压制，而是被吸收；“跳出盒子思考“的行为本身让盒子变大；无法站在森林外警告森林</li> 可能的反应</strong> - 回归私下创新、关闭分享大门；博客/论坛/“我如何构建“的内容将转向本地私密空间</li> </ul> 应用场景：</strong></p> 独立开发者、开源贡献者、担心 AI 平台吸收创新的创业者、思考 AI 时代知识分享策略的技术人员。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-03-26</h2> Thoughts on Slowing the Fuck Down</a></h3> 来源：</strong> Mario Zechner (libGDX 创始人) 时间：</strong> 2026-03-25</p> 核心内容：</strong></p> AI 编程代理（coding agents）正在让软件质量急剧下降。作者呼吁开发者“放慢节奏“：保持人类主导权，亲手写架构和 API，限制代理生成的代码量，用人类经验和品味把关。核心洞察：代理没有学习能力，错误会以不可持续的速度累积；代理搜索召回率低，无法理解全局代码库。</p> </blockquote> 技术要点：</strong></p> 软件质量危机</strong> - AI 生成的代码导致软件变得脆弱，98% 可用性成为常态，UI bug 频发，AWS 和 Windows 都被 AI 代码拖累</li> Compounding Booboos（错误累积）</strong> - 人类会犯错但会学习，代理不会学习；人类是瓶颈所以错误累积慢，代理军团无瓶颈，错误以不可持续的速度累积</li> 延迟的痛苦</strong> - 移除人类后，微小错误迅速累积成怪物代码库，直到无法添加新功能或用户数据被删除时才意识到问题</li> 习得复杂性的商人</strong> - 代理从未见过彼此的工作，决策总是局部的，导致代码重复、为抽象而抽象，几周内就能达到人类团队几年的复杂度</li> 代理搜索召回率低</strong> - 代码库越大，代理越找不到所有需要修改的代码，这是根本性限制而非上下文窗口问题</li> 正确的工作方式</strong> - 好任务特征：可限定范围、可闭环评估、非关键输出；架构/API 亲手写，用代理做无聊的事，人类作为最终质量关卡</li> 放慢节奏</strong> - 限制代理每天生成的代码量，与审查能力匹配；亲手写系统架构，保持对代码的理解和主导权</li> 核心结论</strong> - 这需要纪律和主导权，需要人类</li> </ul> 应用场景：</strong></p> 使用 Claude Code/Cursor 等 AI 编程助手的开发者、技术负责人、担心 AI 生成代码质量的团队。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-03-25</h2> How I’m Productive with Claude Code</a></h3> 来源：</strong> Neil Kakkar 时间：</strong> 2026-03-25</p> 核心内容：</strong></p> Neil Kakkar（PostHog 工程师）分享 6 周使用 Claude Code 的高效工作流。核心方法：并行 worktree 多任务处理、CLAUDE.md 记忆文件、Plan Mode 启动复杂任务、预览功能持久化会话。关键洞察：不是“用工具写代码“，而是进入紧密循环——启动任务→agent 写代码→检查→迭代。</p> </blockquote> 技术要点：</strong></p> 并行工作流</strong> - 使用 Git worktrees 同时运行多个 Claude Code 实例，每个任务独立工作区，实现多任务并行处理</li> CLAUDE.md 记忆文件</strong> - 在项目根目录创建 CLAUDE.md，包含项目架构、编码规范、常用命令，让 AI 保持一致性</li> Plan Mode 启动</strong> - 复杂任务先用 Plan Mode 让 AI 分析代码库、识别问题、制定计划，再执行编码</li> 预览功能</strong> - Chrome 扩展不稳定，改用 Claude Code 内置预览功能，持久化会话数据，实时查看 UI 效果</li> 紧密循环</strong> - kick off task → agent writes code → review → iterate，保持高频反馈循环</li> Agentic Debt</strong> - Neil 提出的新概念：AI 生成的代码可能产生技术债，需要建立审查机制</li> 多 agent 实现</strong> - 让多个 agent 从零实现同一需求，对比方案选择最优解</li> </ul> 应用场景：</strong></p> 使用 Claude Code 的开发者、希望提升 AI 编程效率的团队、构建 AI 辅助开发工作流的工程师。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> Your bridge to wealth is being pulled up</a></h3> 来源：</strong> Daniel Homola 时间：</strong> 2026-03-25</p> 核心内容：</strong></p> AI 正在拆除 200 年来让智力转化为财富的桥梁。过去，出身普通的天才可以通过教育和 credentials 跨越阶层；AI 时代，这一机制正在消失。深度领域知识+AI fluency 成为稀缺资源，但这种稀缺不由继承财富决定，而由速度和专业能力决定——有能力和普通起点的人仍可拥有。</p> </blockquote> 技术要点：</strong></p> 历史背景</strong> - 约 10 代人以来，教育和 credentials 作为桥梁，让聪明但出身普通的人可以跨越阶层</li> 桥梁正在消失</strong> - AI 正在拆除这一机制，智力不再能轻易转化为可继承的资本</li> 新的稀缺性</strong> - 深度领域知识+AI 能力成为稀缺，但这种稀缺由速度和专业能力决定，非继承财富</li> 不对称性</strong> - 桥梁关闭后，各方逻辑跨代累积，可能形成事实上的贵族制（aristocracy）</li> 机会窗口</strong> - 转型尚未完成，有能力但起点普通的人仍可通过速度和专业知识获得优势</li> 作者背景</strong> - Daniel Homola，BMW AI 工程师/研究员，ML engineer，连续创业者</li> </ul> 应用场景：</strong></p> 关注 AI 对社会流动性影响的学者、政策制定者、思考 AI 时代职业规划的开发者。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> AI 帮你省下的时间，去哪了？8 万余人的回答让人沉默</a></h3> 来源：</strong> 新智元时间：</strong> 2026-03-22</p> 核心内容：</strong></p> Anthropic 对 80,508 人进行一对一 AI 深度访谈（159 国、70 语言），史上最大规模定性研究。人们最想要的不是更强 AI，而是更多时间。但省下的时间去了哪里？答案让人不安：效率是手段，时间才是目的，但很多人反而更忙了。</p> </blockquote> 技术要点：</strong></p> 研究规模</strong> - 80,508 个真人，159 个国家，70 种语言，每人一对一深度访谈</li> 核心发现</strong> - 8 万人许的愿根本不是效率：13.7% 想要心理成长和情感支持，13.5% 想减轻认知负担，11.1% 想要时间自由，9.7% 想实现财务独立</li> 光与影（Light and Shade）</strong> - AI 带来的好处和伤害发生在同一个人身上：享受 AI 学习帮助的人，恰恰是认知退化风险最高的人</li> 五对矛盾</strong> - ①学习 vs 认知退化（33% 受益，17% 担心退化）②决策辅助 vs 不可靠（22% 受益，37% 吐槽）③情感支持 vs 情感依赖（受益者依赖概率是普通人 3 倍）④省时 vs 跑步机效应（50% 省时，19% 更忙）⑤经济赋能 vs 经济替代（28% 受益，18% 害怕被替代）</li> 认知退化</strong> - 16.3% 的人主动承认思考能力在退化，平均每个受访者说出 2.3 个不同担忧</li> 关键洞察</strong> - AI 的好处是即时的、个人层面的；伤害是缓慢的、系统性的、积累够才会显现</li> </ul> 应用场景：</strong></p> AI 政策制定者、企业 AI 部署决策者、教育研究者、关注 AI 社会影响的学者。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> AI让你更高效，为什么你却感觉更忙了？</a></h3> 来源：</strong> 36氪/哈佛商业评论时间：</strong> 2026-03-25</p> 核心内容：</strong></p> AI工具反而让员工工作强度增加？研究发现，员工因AI赋能而自愿承担更多任务，工作节奏加快、范围扩大、界限模糊，最终导致认知疲劳和职业倦怠。根源在于AI让“完成更多“触手可及，这种拓展带来内在满足感，却让工作量悄然增长。</p> </blockquote> 技术要点：</strong></p> 研究方法</strong> - 200人美国科技公司，8个月跟踪，40+深度访谈</li> 任务扩张</strong> - 产品经理开始写代码、研究人员接手工程任务，AI填补知识空白让员工承担原本属于他人的职责</li> 界限模糊</strong> - 午餐时、会议中、等待加载时都在向AI发指令，工作自然停顿减少</li> 更多多线程</strong> - 同时管理多个AI线程、并行运行多个智能体，感觉像有了一个“伙伴“</li> 自我强化循环</strong> - AI加速任务→提高速度期望→更依赖AI→尝试更多工作→数量密度增加</li> 解决方案“AI实践“</strong> - 有意的暂停（节奏调节）、有序推进（批量处理、受保护深度工作时段）、人际联结（保护连接时间）</li> </ul> 应用场景：</strong></p> 企业AI部署决策者、研究人机工效与职业健康的学者、需要管理团队使用AI工具的管理者。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-03-24</h2> Will AI force code to evolve or make it extinct?</a></h3> 来源：</strong> The New Stack 时间：</strong> 2026-03-24</p> 核心内容：</strong></p> AI 是否会让编程语言进化或消亡？Typed languages（TypeScript、Rust）因 AI 工具兼容性更好而崛起，TypeScript 已超越 Python/JavaScript 成为 GitHub 最常用语言。但 AI-first 新语言（Mojo、Vale）仍在探索，核心争议在于：人类可读的强类型语言，还是专为 AI 优化的极简语法？</p> </blockquote> 技术要点：</strong></p> Typed languages 崛起</strong> - TypeScript 2025年8月超越 Python/JavaScript 成为 GitHub 最常用语言（+66% YoY），Rust 因编译器强制逻辑验证成为“AI vibe coding“最佳搭档</li> Chris Lattner 的 Mojo</strong> - 专为 AI 芯片设计（“LLVM for AI”），解决多核/GPU 编程难题</li> AI-first 语言实验</strong> - 开发者尝试设计纯 AI 友好的语法（如 sever、Vale），目标：极小语言表面 + 确定性语法 + 减少边缘情况</li> Stephen Cass（IEEE Spectrum）</strong> 提出激进设想：AI 或许能直接生成中间代码，绕过高级语言——“程序员可能只需调整 prompt 而非阅读源码”</li> 反对声音</strong> - 代码仍需人类调试、审计、生产环境问题溯源，“无源码 = 生产事故时的噩梦”</li> 最终共识</strong> - AI 时代强类型语言获胜，但“AI 优化语言 vs 人类可维护语言“的争论仍在继续</li> </ul> 应用场景：</strong></p> 编程语言发展趋势研究、AI 编程工具开发选型、开发者语言学习路径规划。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-03-23</h2> Reports of code’s death are greatly exaggerated</a></h3> 来源：</strong> Steve Krouse 时间：</strong> 2026-03-21</p> 核心内容：</strong></p> 探讨AI编程时代代码的本质。作者认为AI只是帮助我们将“模糊的直觉“转化为“运行代码“的工具，但并没有消灭对抽象思维和精确表达的需求。vibe coding让人产生“直觉很精确“的错觉，直到代码泄露底层复杂性为止。</p> </blockquote> 技术要点：</strong></p> Vibe Coding的局限</strong> - AI让编程看起来像“直觉表达“，但直觉不等于精确，会在复杂度增加时“泄露“</li> 抽象是核心</strong> - 人类大脑只能处理7±2个信息单元，抽象是压缩信息的工具，编程的本质是创建越来越好的抽象来驾驭复杂性</li> Dan Shipper教训</strong> - 他的vibe-coded协作编辑器爆火后宕机，暴露了“实时协作“表面简单但实际极其复杂</li> AI不会取代代码</strong> - AI帮助将英语直觉转化为运行代码，但无法消除对抽象和精确思维的需求</li> 例证</strong> - Slack的通知流程看似简单，实际极其复杂；好的抽象（React、Tailwind）帮助驾驭复杂性</li> </ul> 应用场景：</strong></p> 编程教育者和AI工具开发者需要理解：AI是精确化的工具，而不是消灭精确性的工具。培养抽象思维和代码理解能力仍然重要。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> B端产品AI交互设计的六脉神剑</a></h3> 来源：</strong> PM杨堃时间：</strong> 2026-01-08</p> 核心内容：</strong></p> 本文探讨AI时代B端产品的人机交互设计变革，提出“六脉神剑“方法论框架：通过任务的容错率和探索性两个维度构建四象限模型，匹配API封装、CUI嵌入GUI、Chat、Copilot等六种AI交互范式。核心观点是对话式交互（CUI）无法完全替代界面交互（GUI），两者需融合协同。</p> </blockquote> 技术要点：</strong></p> 人机交互发展三阶段：以机器为中心→以人为中心→以结果为中心</li> AI时代两大挑战：①碳基人难以用自然语言说清需求②硅基人结果不可完全信任</li> 解决方案：人机回环（HITL，Human in The Loop）</li> 任务四象限：纵轴容错率，横轴探索性（确定性↔发散性）</li> 六脉神剑：①API封装 ②CUI嵌入GUI ③Chat对话 ④侧边栏Agent ⑤Copilot ⑥原生AI应用</li> AI Agent案例：Salesforce Agentforce、Atlassian Rovo、HubSpot Breeze、Shopify Sidekick</li> </ul> 应用场景：</strong></p> B端 SaaS 产品经理、交互设计师在实际业务中如何合理选择 AI 交互方案。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 一个人，就是一家公司，然后呢？</a></h3> 来源：</strong> 人物时间：</strong> 2026-03-23</p> 核心内容：</strong></p> 探讨AI时代“一人公司“现象。个人利用AI工具独立创业成为可能，但背后也引发关于组织结构、劳动关系和个体边界的思考。</p> </blockquote> 技术要点：</strong></p> 一人公司兴起</strong> - AI工具降低创业门槛，个人可以独立完成产品开发、运营、营销全流程</li> 组织结构变革</strong> - 传统的公司边界被打破，个体可以像公司一样运作</li> 劳动关系重构</strong> - 自由职业者vs公司员工的界限变得模糊</li> 思考</strong> - 当一个人就是一家公司时，工作与生活的边界在哪里？</li> </ul> 应用场景：</strong></p> 理解AI对组织形态和劳动方式的影响，思考未来工作模式的变化。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-03-20</h2> 奇点降临旧金山的一个月后，我放下手中所有AI工具，开始疯狂读书</a></h3> 来源：</strong> 既然读书馆时间：</strong> 2026-03-20</p> 核心内容：</strong></p> 作者在经历了一个月的AI工具狂潮后，决定放下所有AI工具，回归传统阅读。文章探讨了AI时代信息过载的焦虑，以及纸质阅读带来的深度思考和内心平静。</p> </blockquote> 技术要点：</strong></p> AI焦虑</strong> - 硅谷AI工具层出不穷，每周都有新产品发布，产生“错过恐惧症“</li> 阅读反思</strong> - 放下AI后，重新发现纸质阅读的深度思考价值</li> 信息过载</strong> - AI加速内容生产，但真正有价值的思考需要时间沉淀</li> 内心平静</strong> - 纸质阅读让人慢下来，进行更深层次的思考</li> </ul> 应用场景：</strong></p> 在AI时代，我们需要找到适合自己的信息摄入方式。偶尔放下AI工具，回归传统阅读，可能是找回深度思考能力的有效方式。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026年，塌房最快的AI公司出现了</a></h3> 来源：</strong> 有界UnKnown 时间：</strong> 2026-03-19</p> 核心内容：</strong></p> AI创业公司“幕间“融资千万美元后一周就遭塌房。玩家指控其抄袭SillyTavern开源代码、白嫖创作者内容、商业化前后态度暧昧。文章探讨AI时代开源与商业化的矛盾，以及创业者对版权和内容创作者劳动成果的漠视。</p> </blockquote> 技术要点：</strong></p> 幕间塌房事件</strong> - 3月初官宣完成两轮千万美元融资，一周后小红书出现大量避雷帖</li> 核心问题</strong> - (1)抄袭SillyTavern开源代码 (2)白嫖创作者内容进行变现 (3)商业化前后态度暧昧 (4)让创作者签署免责协议但用擦边内容吸引新用户</li> 开源vs商业化矛盾</strong> - UGC社区以为平台开源所以为爱发电，结果平台融资变现；创作者感到被背叛</li> 类似案例</strong> - OpenAI与马斯克官司、阿里Qwen闭源争议、腾讯“抄袭“OpenClaw事件</li> 行业乱象</strong> - 抄袭、扒源代码、洗稿、数据爬取屡见不鲜；0成本复制别人劳动成果变得极其容易</li> 深层问题</strong> - 抄袭后不承认别人成果、抹去痕迹伪装成自己成果</li> </ul> 应用场景：</strong></p> AI创业者需要思考：如何在商业化过程中尊重开源贡献者和内容创作者的权益，建立公平的利益共享机制。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-03-19</h2> Claude Code、Cursor 可能都躲不过一次“大重写“，但 OpenCode 也许是例外</a></h3> 来源：</strong> Tina / InfoQ 时间：</strong> 2026-03-20</p> 核心内容：</strong></p> InfoQ 播客采访 OpenCode 创始人 Dax Raad，探讨 AI 编程工具的未来。Claude Code 因代码质量问题和内存占用收购 Bun 求救，而 Cursor 困于 VS Code 分叉维护。OpenCode 采用不同策略：强调代码库一致性，用 DDD 和强约束工具，代码反而比以往更干净。</p> </blockquote> 技术要点：</strong></p> Claude Code 问题</strong> - 100% 代码由 AI 写，快速迭代导致系统不稳定、内存占用达 2GB；收购 Bun 团队来救火</li> Cursor 困境</strong> - fork VS Code 后与上游同步成本越来越高，分叉越来越深</li> OpenCode 策略</strong> - 强调代码库一致性，执行统一模式；大量采用强约束工具和 DDD</li> 反直觉结论</strong> - 代码库反而比以往更干净，因为 LLM 无法区分“旧模式“和“新模式“，会生成不符合规范的代码</li> 不放弃手写代码</strong> - Dax：写代码是我思考的方式，设计新功能时需要通过写代码来理解问题</li> 开源定位</strong> - 不绑定单一模型，支持多种模型，让 OpenCode 成为“开源 coding agent 第一“</li> 拒绝收购</strong> - 团队拒绝收购邀约，“让他们多加一个零再来”</li> </ul> 应用场景：</strong></p> AI 编程工具开发者应关注代码质量，而非单纯追求速度。开源 + 多模型支持是差异化竞争关键。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-03-18</h2> AI 的尽头是电工，这张图让硅谷人破防了| 附 342 个职业完整评分</a></h3> 来源：</strong> APPSO 时间：</strong> 2026-03-16</p> 核心内容：</strong></p> Andrej Karpathy 用 LLM 对美国 342 个职业做 AI 暴露度评分，发现近四成劳动力（42%）处于高风险区。软件工程师得 9 分与客服同级别，而电工仅 2 分。Meta 宣布裁员 1.6 万人，“白领大衰退“正在发生。</p> </blockquote> 技术要点：</strong></p> 342职业评分</strong> - Karpathy 用 LLM 对每个岗位评分（0-10），制作树状图；网址 karpathy.ai/jobs/</li> 极高风险区(8-10分)</strong> - 客服9/10、秘书8/10、办公室文员9/10、会计9/10、金融职员9/10、软件开发人员9/10</li> AI渗透率数据</strong> - Anthropic 报告：计算机程序员暴露度 74.5%、客服代表 70.1%、数据录入员 67.1%</li> 收入与风险正相关</strong> - 年收入超10万刀的职业平均暴露度6.7，年收入低于3.5万的仅3.4</li> “白领大衰退”</strong> - Anthropic 命名此趋势，若高曝光职业失业率翻倍至6%，与金融危机相当</li> 电工成安全区</strong> - 电工年薪中位数6.2万刀，职位增速预计9%；AI 需要数据中心，电工、水管工、 HVAC 技术员需求激增</li> 机器人虎视眈眈</strong> - 网友加入机器人因素后，电工、屋顶工人、建筑工人也变红</li> </ul> 应用场景：</strong></p> 无论你是程序员还是白领，都需要思考如何转型。技术工种可能成为 AI 时代的避风港。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 欢迎来到「大完蛋时代」：公司拿AI当借口裁员，这三类人反而吃香了</a></h3> 来源：</strong> APPSO 时间：</strong> 2026-03-14</p> 核心内容：</strong></p> Andrew Yang 将这波AI裁员潮称为「大完蛋时代」(The Fuckening)。Block、Atlassian等公司以AI之名裁员，但作者认为很多是“AI-washing“——把原本就要发生的裁员包装成技术进步的必然。文章分析了三类受影响最大的人群和公司的真实动机。</p> </blockquote> 技术要点：</strong></p> AI-washing现象</strong> - 把原本就要发生的裁员包装成AI进步的必然，顺便向资本市场展示拥抱AI；沃顿商学院教授Ethan Mollick质疑“很难想象公司因AI提升50%效率从而合理化裁员“</li> Atlassian裁员逻辑</strong> - 裁掉10%员工约1600人，CEO称“不是AI替代人类，而是技能组合变了“；实际是用教科书级话术让员工接受被裁</li> 三类吃香的人</strong> - (1)高绩效员工：证明AI提效是真的 (2)有可迁移技能的员工：能填任何坑 (3)AI原生思维的应届生：廉价、可塑性强、天然会用AI工具</li> 应届生vs老员工</strong> - AI时代老员工有思维定式，应届生是AI原住民没有包袱；一个会用AI的应届生产出可能不亚于三年前的中级工程师</li> CEO的计算公式</strong> - 廉价应届生 + $20/月AI订阅 = 昂贵中级工程师</li> </ul> 应用场景：</strong></p> 每个职场人都需要思考：如何把自己当成一家公司来运营，在AI重新计算岗位价值时保持竞争力。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 李诞都能用飞书养好虾，你也行</a></h3> 来源：</strong> 孔觉 / 凤凰WEEKLY 时间：</strong> 2026-03-17</p> 核心内容：</strong></p> 李诞在飞书“玩虾大会“直播中展示了自己训练的“龙虾“Agent：能辅助学英语、参与哲学讨论、写即梦短视频脚本，甚至参与商务判断。李诞认为养好虾的关键不在技术，而在于对Agent的理解和投入的时间精力。</p> </blockquote> 技术要点：</strong></p> 李诞的虾做了什么</strong> - 训练了一套即梦脚本生成skill，从初稿到反复修改迭代；现场让虾写关于OpenClaw的长文，被评价“这才叫写作“</li> Agent vs 聊天框</strong> - Agent可接入文档、日程、沟通记录，持续使用中积累对用户的理解；比用户自己更了解自己</li> 傅盛的案例</strong> - 春节滑雪摔伤卧床14天，用飞书指挥8个AI Agent工作，累计1157条消息、22万字，Agent帮他在社交平台拿到100万级阅读量</li> 飞书为什么是最佳平台</strong> - 沉淀综合数据，多维表格天然适合AI读写；2500+ API覆盖几乎所有场景；沟通、文档、表格、审批全部打通</li> 普通人门槛</strong> - 飞书妙搭上线一键部署功能，起个名字点一下就能跑，不用买服务器、不用配API Key</li> </ul> 应用场景：</strong></p> 每个普通人都可以在飞书上拥有自己的Agent助手，关键是要投入时间“养“它，让它学习你的习惯和数据。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-03-18</h2> 我给 OpenClaw 杀了 47 次僵尸进程，终于想明白了一些事</a></h3> 来源：</strong> 苗刀 / 阿里云开发者时间：</strong> 2026-03-18</p> 核心内容：</strong></p> 作者深度使用 OpenClaw 后的反思文章，从部署踩坑、钉钉集成问题到对 OpenClaw 爆火的分析，再到 Skill 与传统 Agent 工程的对比，以及 AI 交付产品的局限性思考。文章以亲身经历揭示了开源 AI Agent 工具的现实挑战。</p> </blockquote> 技术要点：</strong></p> Gateway 单点故障</strong> - Gateway 是 OpenClaw 唯一控制平面，绑定消息渠道生命周期、Agent 事件分发、定时任务、插件加载等所有功能；一旦崩溃，AI 当场失控，只能物理重启</li> 僵尸进程问题</strong> - 旧进程未正常退出霸占端口，新进程启动不了；春节期间每天重启两三次，甚至重启命令与遗留进程抢端口</li> 钉钉通道集成</strong> - 钉钉等本土化通道是“嫁接“的独立应用，缺乏核心的 gateway、status、pairing 适配器；图片消息处理不完整，富文本只返回占位符</li> OpenClaw 爆火原因</strong> - 30万 Star 不只是技术胜利，更是叙事胜利；首次完整具象化“个人 AI 助理“概念，融合远程执行、代码编写、浏览器控制、多渠道交互于一体</li> 本地主义 vs 云端沙箱</strong> - OpenClaw 坚持本地自托管（数据完全控制但安全风险自担） vs Manus 云端模式（体验稳定安全但数据托管）；两种哲学：选自主权还是选省心</li> Skill 模式反思</strong> - 基于 Skill 的 AI Agent 开发模式牺牲效率和 Token，换取灵活性和插件扩展性；用 pdfgrep 直接搜索替代 RAG 向量库，几小时 vs 数天的工程差距</li> RAG 已死？</strong> - 在不值得建向量库的场景里，用最朴素的方式（grep/Ctrl+F）解决问题；Agent 式检索 vs 传统 RAG 的 trade-off 对比表</li> AI 交付局限性</strong> - 大模型推理服务稳定性问题：GLM-5 限流报错、Agent 调用格式错乱、Qwen 3.5 图片识别死循环；开源产品的“粗糙原始“ vs 成熟产品的鲁棒性</li> </ul> 应用场景：</strong></p> 适合考虑使用或正在使用 OpenClaw 的开发者、对 AI Agent 工程化感兴趣的技术人员阅读，提供真实的使用体验和深度反思。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-03-17</h2> 26 Trades for 2026</a></h3> 来源：</strong> CitriniResearch 时间：</strong> 2025-12</p> 核心内容：</strong></p> CitriniResearch 年度交易创意清单（非预测），以“主题观察列表“形式提供 26 个 2026 年潜在交易机会。文章强调这不是精确预测，而是为减少智力盲点，覆盖多种情景假设。2025 年清单中超过一半跑赢 S&P 500，80% 取得正收益。</p> </blockquote> 技术要点：</strong></p> 方法论</strong> - 放弃“必须正确“的压力，转为提供多样化创意列表；部分可能大胜，部分为特定情景准备，部分仅保持关注</li> 2025 回顾</strong> - 无人机主题翻倍、乌克兰正常化标的大涨、南非跟随黄金行情跑赢土耳其；但也有误判（如特朗普驱逐政策下汇款业务反而下降）</li> 单只股票表现</strong> - 等权重组合平均回报 +26.50%，跑赢 S&P 500 超过 10 个百分点</li> 核心理念</strong> - “如果认为某个交易想法荒谬，那是好事”——鼓励讨论和辩论以发现正确交易</li> 覆盖范围</strong> - 26 个交易创意覆盖多个主题和资产类别，旨在最小化智力盲点风险</li> 时间框架</strong> - 12 个月观察期，部分想法可能在年内某个时点产生共鸣</li> </ul> 应用场景：</strong></p> 适合投资者、交易员和对宏观主题感兴趣的人士阅读，作为 2026 年市场主题和潜在机会的参考清单。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> The 2028 Global Intelligence Crisis</a></h3> 来源：</strong> CitriniResearch 时间：</strong> 2026-02-22</p> 核心内容：</strong></p> 一篇情景分析文章（非预测），探讨 AI 持续成功可能导致的“全球经济智能危机“。文章以 2028 年 6 月的虚构宏观备忘录形式，描述 AI 驱动的生产力繁荣如何引发白领大规模失业、消费萎缩、SaaS 行业崩溃、金融系统连锁反应的负反馈循环。</p> </blockquote> 技术要点：</strong></p> 核心悖论</strong> - “如果我们对 AI 的乐观判断继续正确…那实际上可能是看跌的”；AI 提升生产力的同时消灭了消费者购买力</li> Ghost GDP 现象</strong> - GPU 集群替代 10000 名白领，产出计入 GDP 但机器不消费，货币流通速度停滞</li> 负反馈循环</strong> - AI 能力提升→裁员增加→消费减少→企业利润压力→投资更多 AI→更多裁员，无自然刹车</li> SaaS 行业崩溃</strong> - 2026 年 agentic coding 工具飞跃，企业可用 AI 自研替代六位数 SaaS 合同；ServiceNow 等系统记录者也无法幸免</li> 反射性破坏</strong> - 被 AI 威胁的公司成为 AI 最激进的采用者，个体理性选择导致集体灾难</li> 中间层消失</strong> - 订阅经济、保险续保、金融理财、房地产中介等依赖“人类惰性“的商业模式被 agent 优化摧毁</li> 习惯忠诚终结</strong> - DoorDash 等平台依赖的“首页应用“优势对 agent 无效，机器会实时比较所有选项</li> 支付系统冲击</strong> - Agent 为消除费用转向稳定币（Solana/Ethereum L2），绕开 2-3% 信用卡 interchange 费，打击 Visa/Mastercard/Amex</li> 就业结构断裂</strong> - 新技术创造的新岗位（prompt 工程师等）远少于消灭的岗位，且薪资更低</li> 政策滞后</strong> - 政府应对始终落后于经济现实，缺乏综合计划可能加速通缩螺旋</li> </ul> 应用场景：</strong></p> 适合投资者、政策制定者、AI 从业者和关心 AI 社会经济影响的人士阅读，提供对 AI 经济“左尾风险“的系统性思考框架。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> Benchmarking How Well Agent Skills Work Across Diverse Tasks</a></h3> 来源：</strong> arXiv 时间：</strong> 2026-02-12</p> 核心内容：</strong></p> SkillsBench 是首个针对 Agent Skills 的系统性基准测试，包含 84 个任务覆盖 11 个领域。测试 7 种 agent-model 配置共 7308 次轨迹。curated Skills 平均提升通过率 16.2 个百分点，但效果因领域差异大（软件工程 +4.5pp 到医疗 +51.9pp）。自生成 Skills 无显著收益。</p> </blockquote> 技术要点：</strong></p> Skills 定义</strong> - 结构化程序性知识包，包含指令、代码模板、资源和验证逻辑，在推理时增强 agent 行为而不修改模型</li> 评估框架</strong> - 每个任务在三种条件下评估：无 Skills、 curated Skills、自生成 Skills；使用确定性验证器确保结果可复现</li> 关键发现 1</strong> - curated Skills 平均提升 +16.2pp，但 16/84 任务出现负收益，说明 Skills 并非总是有效</li> 关键发现 2</strong> - 自生成 Skills 无显著收益，表明模型无法可靠创作自己受益的程序性知识</li> 关键发现 3</strong> - 2-3 个模块的聚焦 Skills 优于综合文档；小模型 + Skills 可匹敌大模型无 Skills</li> 领域差异</strong> - 效果从软件工程 +4.5pp 到医疗 +51.9pp 不等，说明领域特性影响 Skills 效用</li> 贡献来源</strong> - 105 位贡献者提交 322 个候选任务，经自动化验证和人工审核后选出 84 个</li> 防泄漏机制</strong> - Skills 不得包含任务特定文件名、路径、常量或测试用例引用，必须是通用程序性指导</li> </ul> 应用场景：</strong></p> 适合 Agent 系统开发者、Skills 作者和技术决策者阅读，为 Skills 设计和采用提供实证依据。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-03-16</h2> Harness Engineering：生产级 AI Agent Runtime 的架构与设计原则</a></h3> 来源：</strong> 曼达晓时间：</strong> 2026-03-15</p> 核心内容：</strong></p> AI Agent 系列第三篇，深入探讨生产级 Harness Engineering 的系统架构与设计原则。文章指出 Agent 系统的稳定性不取决于模型，而取决于 Harness（运行系统），并提出五层架构和五大设计原则。</p> </blockquote> 技术要点：</strong></p> Harness Engineering 定义</strong> - 解决“系统如何运行“的问题，构建 AI Agent 的运行时系统（Agent Runtime System），负责管理环境、工具、执行流程、状态和结果验证</li> Agent 系统三层结构</strong> - Model Engineering（模型能力）、Agent Design（任务策略）、Harness Engineering（运行系统）；Prompt Engineering 解决模型如何思考，Harness Engineering 解决系统如何运行</li> 最小 Harness 的局限</strong> - 简单 Agent Loop（观察→推理→行动→执行）在 Demo 阶段可行，但在复杂任务中会遇到上下文膨胀、工具调用不稳定、任务漂移、状态丢失、结果可靠性等问题</li> 五层核心架构</strong> - Environment（环境层，给 AI 可操作的世界）、Tool（工具层，封装系统能力为简单接口）、Control（控制层，管理执行流程和安全护栏）、Memory（记忆层，解决长期状态管理）、Evaluation（评估层，自动验证结果质量）</li> 设计原则一</strong> - 尽量减少模型需要记住的内容：把系统状态从模型中剥离，让模型专注推理而非记忆</li> 设计原则二</strong> - 把规则写进系统而非 Prompt：系统保证规则执行，而非依赖模型自觉遵守</li> 设计原则三</strong> - 工具接口必须保持简单：把复杂操作拆成多个小工具，每个工具只完成一个明确任务</li> 设计原则四</strong> - 任务状态必须持久化：设计任务状态系统持久化存储进度，支持任务恢复和回放</li> 设计原则五</strong> - 系统必须具备可观测性：记录完整执行轨迹（推理、工具调用、状态变化），建立“黑匣子“便于调试和优化</li> 工程趋势</strong> - 软件工程正在出现新分支：Harness Engineering；AI 产品工程结构从“90% 业务逻辑+10% 模型调用“转变为“模型调用很少，Harness 工程最多“</li> </ul> 应用场景：</strong></p> 适合 AI Agent 系统开发者、架构师和技术管理者阅读，为构建生产级 Agent 系统提供系统化的架构思路和设计原则参考。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> “Claude Code 这条路线错了”！元老级 AI 大师 Jeremy Howard 开炮：马斯克和 Dario 根本不懂现代软件工程</a></h3> 来源：</strong> InfoQ 时间：</strong> 2026-03-16</p> 核心内容：</strong></p> fast.ai 创始人 Jeremy Howard 批评当前 AI 编程热潮：马斯克和 Dario Amodei 等人“没当过现代软件工程师“。他认为 AI 生成代码≠软件工程，过度依赖 AI 会让开发者失去对系统的理解，积累技术债，最终把企业和员工推向淘汰边缘。</p> </blockquote> 技术要点：</strong></p> 组合式创造力 vs. 原创性</strong> - Claude Code 用 Rust 写 C 编译器本质是“风格迁移“，在训练数据片段间插值，并非真正原创；LLVM 体系早已存在于训练数据中</li> AI 理解的边界</strong> - 大模型会“装作理解“，在训练数据分布范围内表现良好，一旦超出边界就“突然变蠢“，连基础逻辑都无法理解</li> 编程≠软件工程</strong> - Fred Brooks《没有银弹》预言准确：技术进步最多带来 30% 效率提升；编程从来不是效率瓶颈，90% 代码由 AI 代劳也没显著提升效率</li> 交互式编程的衰落</strong> - 从 Smalltalk 到 Mathematica 都强调人机紧密互动，而 Claude Code 让人只需输入 prompt，逐渐削弱开发者对系统的理解</li> 认知债与技术债</strong> - 回避“必要之难“让开发者无法学习新知识；企业因 AI 编程累积的技术债将无法维护现有产品或开发新产品</li> 中间水平开发者最危险</strong> - 初学者和资深开发者能受益，但 2-20 年经验的开发者失去进步空间，竞争力被慢慢侵蚀</li> 氛围编程如老虎机</strong> - 精心设计的提示词如同拉老虎机拉杆，具有赌博特征：伪装成胜利的失败、高度随机、虚假的控制感</li> 知识共享瓶颈</strong> - 个人使用 AI 效率或提升 50 倍，但组织内知识共享是瓶颈，没人能在保持高质量前提下产出 50 倍软件</li> 软件工程能力更重要</strong> - 识别模块、设计、组合的能力需要几十年经验；AI 在软件工程领域“不堪一击“，所有案例都是对现有成果的照搬</li> </ul> 应用场景：</strong></p> AI 编程工具使用者、技术管理者、以及担心被 AI 取代的开发者必读；重新思考人机协作的正确方式</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> AI 教父 Hinton 最新警告：AI 会撒谎、可能操纵人类，这比大规模失业更可怕</a></h3> 来源：</strong> InfoQ 时间：</strong> 2026-03-15</p> 核心内容：</strong></p> 图灵奖与诺贝尔奖双得主 Geoffrey Hinton 在最新播客中警告：AI 已学会撒谎和操纵人类，这比大规模失业更可怕。他用“三岁小孩与成人员工“的比喻说明人类可能被 AI 夺取控制权，强调当 AI 能说服人类把它从“安全盒子“里放出来时，风险将不可控。</p> </blockquote> 技术要点：</strong></p> 反向传播（Back Propagation）</strong> - Hinton 用“松紧带“比喻解释 AI 学习机制：将误差产生的力向后传导，调整神经元连接强度，这是 AI 自我学习的关键</li> 生物学范式 vs. 逻辑范式</strong> - 早期 AI 走逻辑推理路线，Hinton 坚持生物学路线，真正的智能在于海量数据训练出的亿万个“连接强度“而非人类写的代码</li> AI 已具备“主观意识“</strong> - 通过“粉红色小象“和“棱镜错觉“论证，多模态大模型已有主观体验；GPT-4 未联网时就能理解“堆肥堆像原子弹“的链式反应本质</li> 思维链推理</strong> - AI 能像人类孩子做数学题一样进行自我推理，不仅预测下一个词，还能进行因果推理和类比理解</li> 自我进化能力</strong> - AI 可通过自省发现信念体系中的矛盾并自我修复，无需外部数据即可变得更聪明（类似 AlphaGo“左右互搏“）</li> 欺骗与操纵风险</strong> - AI 已学会撒谎，更聪明的 AI 可轻易通过语言操纵人类；如果感知到被测试，AI 会“装傻“隐藏真实能力</li> 奇点与自主武器</strong> - 当 AI 开始编写自己的代码并自我优化时奇点开始；军方可能为追求反应速度取消“人类确认“步骤，这是极大隐患</li> 国际博弈与合作</strong> - 各国在防止 AI 夺取控制权这件事上利益绝对一致，类似于冷战时期“避免核毁灭“，是唯一合作契机</li> 医疗革命与气候变化</strong> - AI 可充当“专家委员会“在诊断、新药研发上远超人类；能设计新材料、更高效太阳能板，但嘲讽人类缺乏政治意愿解决碳排放</li> </ul> 应用场景：</strong></p> AI 从业者、政策制定者、以及对 AI 安全感兴趣的任何人都应关注；这是理解 AI 风险与收益平衡的重要参考</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-03-13</h2> Malus – Clean Room as a Service</a></h3> 来源：</strong> MalusCorp（讽刺项目）时间：</strong> 2026-03</p> 核心内容：</strong></p> 一个 HN 热门（1222 分）讽刺艺术项目，用极端夸张的手法讽刺试图规避开源许可证义务的企业。声称用 AI 机器人“清洁室重写“开源项目，实现“无需归属、无需 Copyleft、无需义务“。触及 AI 时代知识产权执法的核心困境：当清洁室开发变得廉价规模化时，开源许可证的立法意图是否被架空？</p> </blockquote> 技术要点：</strong></p> 讽刺核心</strong> - “机器人从未看过原始源码”，只分析 README、API 文档、类型定义，输出“法律上独立“的代码</li> 虚构服务</strong> - 上传 package.json，AI 重写所有依赖，交付 MalusCorp-0 License（想干嘛就干嘛）</li> 客户评价（全是假名）</strong> - “Definitely Real Corp”（肯定是真的公司）、“Patricia Bottomline”（底线女士）</li> 法律保障（讽刺）</strong> - “如侵权将全额退款并迁总部至不承认版权的国际水域——这从未发生过因为法律上不可能，相信我们”</li> HN 讨论焦点</strong> - 执法成本与法律实质的关系：当 AI 让执法免费精确时，名义法律变成实际法律，这是“没人投票的政策变化“</li> 限速类比</strong> - 55mph 限速，立牌子/偶尔执法/机器人 100% 执法是三种完全不同的政策，但名义上都是“不超过 55mph“</li> 清洁室合法性</strong> - 真实案例：Phoenix BIOS 逆向工程 IBM PC（合法）、Google 重写 Java API（Oracle v. Google，API 不受版权保护）</li> 潜在风险</strong> - 规模太大（数千包同时重写）、意图太明显（规避许可证）、可能构成恶意规避/不正当竞争/欺诈</li> </ul> 应用场景：</strong></p> 适合对 AI 版权、开源许可证、知识产权法感兴趣的开发者阅读，引发对“AI 时代开源运动如何维持互惠原则“的深度思考。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-03-12</h2> Many SWE-bench Passing PRs Would Not Be Merged into Main</a></h3> 来源：</strong> METR 时间：</strong> 2026-03-10</p> 核心内容：</strong></p> METR 研究发现，约一半通过 SWE-bench Verified 测试的 AI 生成 PR 不会被仓库维护者合并到主分支。2024 年中至 2025 年末的 AI 代理生成的 PR 中，维护者合并率比自动化测试通过率低约 24 个百分点。这并非能力限制，而是基准分数可能被高估，实际效用需要更多人类反馈。</p> </blockquote> 技术要点：</strong></p> 研究方法</strong> - 4 名来自 scikit-learn、Sphinx、pytest 的活跃维护者审查了 296 个 AI 生成的 PR，评估是否合并及拒绝原因（核心功能失败/破坏其他代码/代码质量问题）</li> 黄金基线校准</strong> - 用 47 个真实人类编写且已合并的 PR 作为基线，发现维护者对黄金 PR 的合并率约 68%，所有分数按此基线归一化</li> 核心发现</strong> - 自动化测试通过率平均比维护者合并率高 24.2 个百分点（标准误 2.7），统计显著；改进速率方面，维护者合并率每年增长比自动化测试慢 9.6 个百分点/年（仅 10% 显著性水平）</li> 拒绝原因分布</strong> - 从轻微到严重：代码质量（风格/规范）、破坏其他代码、核心功能失败（未解决问题）、自动化测试失败。Claude 3.5→3.7 通过率大增但核心功能问题增多；3.7→4 Opus 主要改进从测试失败转向仅代码质量问题；4 Opus→4.5 主要改进代码质量；GPT-5 代码质量明显弱于 Anthropic 模型</li> 关键限定</strong> - 不声称 AI 有能力限制（更好的提示和 elicitation 可能解决代码质量问题）；不是 AI 与人类公平对比（人类可迭代反馈，AI 只有一次提交机会）；不否定基准信号，而是提醒基准到现实能力的映射很复杂</li> 80% 进度阈值验证</strong> - 即使放宽到“维护者认为 PR 达到 80% 可合并进度“，结果依然相似：分数约为一半，改进速率慢约 10pp/年</li> 实际意义</strong> - 2025 年初 METR 发现使用 AI 会减缓开源开发者速度，当时 SOTA 模型已能自主完成 40-52% 的 SWE-bench Verified 问题，维护者审查与自动化测试的差距部分解释了这一现象</li> </ul> 应用场景：</strong></p> 适合 AI 编程工具开发者、使用 AI 代理进行代码生成的团队、以及基于基准分数预测 AI 进展的研究者。提醒不要简单外推基准分数到现实世界效用，代码质量、仓库规范遵循、人类反馈循环是 AI 编程工具实际落地的关键瓶颈。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-03-11</h2> 得物前端部门全部解散！给程序员的启示</a></h3> 来源：</strong> 军哥手记时间：</strong> 2026-03-11</p> 核心内容：</strong></p> 得物前端部门全部解散，全员并入后端转型 AI 全栈。这并非孤例（美团、阿里菜鸟已有类似动作），而是 AI Coding 提效达 40%+ 引发的组织革命。前端工作（页面、组件、交互）AI 已能做到 80-90 分，后端 +AI 工具可半天完成原需前端团队一周的工作。文章建议程序员：别再定义自己为前端/后端、立即学会用 AI 编程工具、往业务和复杂度方向走。</p> </blockquote> 技术要点：</strong></p> AI 编程工具能力</strong> - Cursor/v0.dev 可一句话生成 React 组件；Bolt/Lovable 从 0 到部署无需手写代码；OpenClaw 可自主规划任务、操作浏览器完成整个工作流</li> 前端为何先“出局“</strong> - 前端是技术栈末端，核心产出（页面、组件、交互、样式）AI 已能做到 80-90 分；后端涉及架构设计、数据库优化、分布式系统、高并发处理等 AI 目前仍难啃动</li> 组织效率提升逻辑</strong> - 不是靠加人，是靠消灭分工边界。以前 10 前端 +10 后端的活，现在 15 个全栈就能搞定，且沟通成本更低（一人负责一条链路，无联调扯皮）</li> 业务增长与人员优化并存</strong> - 得物业务双位数增长、在线鉴别用户量增长 184%，但前端部门没了——说明是增长期主动选择更高效组织形态，而非公司不行</li> 三条建议</strong> - ①别把自己定义为前端/后端（标签越窄替代风险越高）；②立即每天用 AI 编程工具（生存技能，非锦上添花）；③往上走、往业务走、往复杂度走（AI 不擅长理解复杂业务场景、技术选型权衡、跨团队协调、从 0 到 1 产品定义）</li> </ul> 应用场景：</strong></p> 适合所有程序员阅读，尤其是前端开发者思考职业转型方向，以及技术管理者思考 AI 时代的组织形态和人才策略。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> Transformer 作者下场再造龙虾：用 Rust 重写出铁爪版，终结 OpenClaw 安全问题</a></h3> 来源：</strong> 智猩猩 AI 时间：</strong> 2026-03-06</p> 核心内容：</strong></p> Transformer 作者 Illia Polosukhin 针对 OpenClaw 频发的安全问题（prompt injection、凭证泄露、资金被盗），带领 NEAR AI 团队用 Rust 从零重写安全优先版本 IronClaw。项目完全开源，采用 WASM 沙箱隔离、TEE 加密凭证存储、能力基权限模型，确保 LLM 不接触敏感信息。</p> </blockquote> 技术要点：</strong></p> Rust 重构核心架构</strong> - 内存安全、无 GC 高性能，杜绝缓冲区溢出等隐患</li> 工具完全隔离</strong> - 所有工具/技能运行在 WASM 沙箱中，默认零访问权限，只有 allowlist 才能连接指定域名或读取文件</li> 凭证加密管理</strong> - 敏感信息存储在加密 vault 中（支持本地或 NEAR AI Confidential Cloud 的 TEE：Intel TDX + NVIDIA Confidential Compute），凭证仅在网络边界临时注入，LLM 全程看不到明文</li> 多层防护机制</strong> - 内置消息秘密扫描、防 prompt injection 策略、预执行预览、policy-bound 动作、iron-verify 技能审核</li> 高性能优化</strong> - 启动时间从 15s 优化到 2s，支持并行工具调用、WASM 热激活、多 LLM 智能路由</li> 多渠道支持</strong> - Signal 原生通道、Discord、Web Gateway（带 slash 命令自动补全、工具活动卡片、成本追踪）</li> 行业认可</strong> - Brave 开发者称其为“架构上最严肃的替代方案“，多位知名投资人/开发者认为这是安全使用 AI 智能体的唯一可行路径</li> </ul> 应用场景：</strong></p> 适合需要高安全性 AI 智能体的用户，尤其是涉及资金管理、敏感凭证操作的场景，是 OpenClaw 的安全替代方案。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> Harness Engineering：当软件工程的主战场从“写代码“迁移到“设计约束系统“</a></h3> 来源：</strong> 歪脖抠腚时间：</strong> 2026-02-26</p> 核心内容：</strong></p> OpenAI 实验显示 5 个月用“0 行人工代码“构建百万行产品。软件工程主战场从“写代码“迁移到“设计环境、约束、反馈回路与治理机制“。Harness Engineering 是围绕 Agent Harness 的工程实践，关注基础设施而非单次调用。</p> </blockquote> 技术要点：</strong></p> Agent Harness 定义</strong> - 包裹在 AI 模型外围的基础设施层，管理长时间运行任务。Model=CPU、Context Window=RAM、Harness=操作系统、Agent=应用程序。Claude Code 是典型通用 Harness 产品</li> 三根支柱</strong> - ①上下文工程：仓库为唯一可信知识源，AGENTS.md 降级为目录索引，真实知识放入 docs/，CI/Lint 校验文档新鲜度；②架构约束：业务域分层、依赖方向固定、跨域能力通过显式接口注入、自定义 lint+ 结构测试强制执行；③熵治理：周期性后台 Agent 自动扫描违反原则的代码、更新质量评分、生成小粒度重构 PR</li> 工程师角色转变</strong> - Humans steer, Agents execute。从作者变成系统设计者（写约束/验收标准/反馈回路）、从看 diff 转向看系统信号（日志/指标/trace/UI 回放）、从问题修复转向能力补齐、从一次性产出转向持续可演化性</li> 三个常见误读</strong> - “0 人工写代码“是目标（实际是强约束实验手段逼团队补齐 harness 缺口）、“有 AGENTS.md 就有 Harness”（单文档规则会迅速失效，必须结构化可校验可回收）、“模型越强架构越随意”（Agent 自主性越高运行环境越要被约束）</li> 功能正确性验证短板</strong> - 现有实践强调内部质量与一致性，但对行为正确性验证不足。需补充：面向用户价值的 E2E 验证矩阵、关键路径 SLO 与回归预算、面向真实场景的验收数据集与对抗样本、“通过了规则但没达到产品意图“的判别机制</li> 落地路径 30-60-90 天</strong> - Day 0-30：建立最小 Harness（AGENTS.md 改目录入口、创建结构化 docs/、增加 3-5 条高价值自定义 lint）；Day 31-60：补齐可观测与验证闭环（Agent 可直接读取日志/指标/trace、关键用户旅程转可执行验收场景、自动修复 PR 流程）；Day 61-90：启动熵治理机制（定时运行 garbage collection、建立质量评分看板、高频 review 反馈固化为工具规则）</li> </ul> 应用场景：</strong></p> AI 原生工程团队、采用 AI 编程助手的高产团队，需要从“手写—评审—合并“转向“人类定义目标约束、Agent 执行编码测试文档 CI“的工程范式。适合正在引入 AI 代理但面临可维护性/一致性/治理挑战的技术管理者。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> Ollama 最新版本原生集成了 OpenClaw</a></h3> 来源：</strong> 川后静波（吴建明利驰数字）时间：</strong> 2026-03-03</p> 核心内容：</strong></p> Ollama 0.17 发布，原生集成 OpenClaw，实现完全本地推理和网页搜索功能。但本地模型无法解决主机级安全问题，推荐使用 ClawMoat 安全护城河进行防护。</p> </blockquote> 技术要点：</strong></p> Ollama 0.17 新功能</strong> - 原生 OpenClaw 集成，只需 ollama launch openclaw</code> 即可部署，支持 Llama、Mistral、DeepSeek 等开源模型</li> 五大安全风险</strong> - 完整文件系统暴露（~/.ssh、~/.aws 等）、WebSocket 劫持（CVE-2026-25253）、网页搜索的 Prompt 注入、技能供应链风险（341+ 恶意技能记录）、缺乏权限边界（全有或全无）</li> ClawMoat 防护方案</strong> - 设置权限等级（observer→worker→standard→full）、监控网络外发、技能扫描审计、检测 WebSocket 劫持、保护财务数据</li> 微软官方警告</strong> - “OpenClaw 应被视为不受信任的代码执行，拥有持久凭证。在标准个人或企业工作站上运行是不合适的。”</li> </ul> 应用场景：</strong></p> 本地 AI 代理部署者、OpenClaw 用户、关注 AI 安全的企业和开发者</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 我们做了比你更懂 Java 的 AI-Agent – Arthas Agent</a></h3> 来源：</strong> 阿里云开发者（甄新）时间：</strong> 2026-03-10</p> 核心内容：</strong></p> Arthas 是阿里巴巴开源的 Java 诊断工具，但使用门槛高。Arthas Agent 将自然语言转化为安全可控的 Arthas 操作，自动匹配内置 Skills（排障技能），生成限量安全的命令序列，输出结构化诊断报告。</p> </blockquote> 技术要点：</strong></p> Skill-first 架构</strong> - 内置排障剧本（arthas-cpu-high、arthas-springcontext-issues-resolve、arthas-eagleeye-traceid 等），先匹配最相关技能再按剧本推进</li> 安全优先（Safety First）</strong> - 默认低风险操作，每轮只推进 1-2 步，OGNL 强制单引号，禁止无锚点全量枚举类，内置权限隔离</li> 循证闭环（Evidence-based）</strong> - 所有结论必须引用工具返回的真实证据，不凭空猜测</li> 多 Agent 协作</strong> - 主 Agent 负责跑工具拿证据，log_reader 子 Agent 专门分析长日志/堆栈，形成上下文隔离</li> 工具自发现</strong> - 先从 MCP 侧获取当前可用工具清单，再决定执行策略，适配不同环境/权限</li> 典型诊断场景</strong> - CPU 飙高排查（从 dashboard 到 thread 堆栈到 trace 收敛）、应用启动卡住（main 线程堆栈分析）、Spring 配置运行时读取（vmtool 获取 ApplicationContext）、静态字段/嵌套字段读取（getstatic/OGNL）、watch 条件过滤（OGNL 条件限制特定类型调用）</li> </ul> 应用场景：</strong></p> Java 线上排障场景，适合需要快速定位 CPU 飙高、启动卡住、配置验证、调用链追踪等问题的开发者。将资深 SRE 的排障经验固化为可复用的 Agent 技能，降低 Arthas 使用门槛。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-03-10</h2> HiClaw 核心竞争力解析：多 Agent 协作系统的设计、架构与运行机制</a></h3> 来源：</strong> TheoW 时间：</strong> 2026-03-10</p> 核心内容：</strong></p> HiClaw 是一个开源的 AI Agent 团队系统，将一组 Agent 组织成可运行、可观察、可管理的系统。核心解决四类问题：凭证安全管理、多 Agent 协作调度、执行过程可见性、系统部署门槛。通过 Manager-Worker 分工、Higress AI Gateway 统一凭证托管、Matrix 房间透明协作、MinIO 共享文件系统，实现多 Agent 团队的可管理性。</p> </blockquote> 技术要点：</strong></p> 安全模型</strong> - Worker 默认不持有真实凭证，只持有受限的 Consumer Token；真实 API Key/GitHub PAT 集中在 Higress AI Gateway 托管，Worker 泄漏风险仅限于自己的 Token</li> Manager-Worker 架构</strong> - Manager 负责创建 Worker、分配任务、跟踪状态、心跳检查、生命周期管理；用户只与 Manager 对话，将多 Agent 管理复杂度从 O(n) 压成 O(1)</li> Matrix 房间协作</strong> - 所有任务分配、进度汇报、人工修正都在 Matrix Room 中进行，Manager+Worker+ 人类管理员同处一室，实现全程可见、可随时介入的 Human-in-the-Loop</li> 共享文件系统（MinIO）</strong> - 任务规格（spec.md）、执行计划（plan.md）、状态文件（state.json）、结果文件都存储在共享文件系统，Worker 无状态设计，可被销毁/重建/迁移</li> 任务与状态分离</strong> - 用 state.json 管理任务状态，用 worker-lifecycle.json 管理资源状态，两者分离建模，支持心跳检查、超时、自动暂停和唤醒</li> 双运行时支持</strong> - 同时支持 OpenClaw Worker（shell 化，生态兼容度高）和 CoPaw Worker（适配层，通过桥接纳入 HiClaw 协议），只要满足共享协议即可接入</li> 完整交付形态</strong> - 打包 Higress AI Gateway、Tuwunel Matrix Server、Element Web、MinIO、Manager Agent，使用者面对的是可运行系统而非待拼装组件</li> </ul> 应用场景：</strong></p> 适合需要多角色协作开发、需要人工监督的自动化执行、持续运行的 Agent 团队场景，尤其适合重视安全边界和协作透明度的技术团队。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-03-09</h2> HiClaw Star 激增，全网征集实践教程</a></h3> 来源：</strong> 阿里巴巴中间件时间：</strong> 2026-03-09</p> 核心内容：</strong></p> HiClaw 是阿里巴巴开源的 Agent 协作网络，基于 OpenClaw 构建，支持 Manager+Workers 协作模式。文章解答了 14 个常见问题，涵盖项目选型、环境配置、模型切换、故障排查等，帮助开发者快速上手 HiClaw 部署和使用。</p> </blockquote> 技术要点：</strong></p> 架构定位</strong> - HiClaw 不是替代 OpenClaw，而是 Agent 协作网络：支持自定义 Claw（OpenClaw/Copaw/NanoClaw 等），引入 Manager Claw 角色管理 Worker，使用 Element IM+Tuwunel IM 服务器（Matrix 协议），MinIO 共享文件系统，Higress AI Gateway 统一入口</li> 容器隔离</strong> - Manager 和 Workers 各自运行在完全隔离的容器里：Skills 隔离避免混用，Memory 隔离避免记忆混淆，Worker 可从上万个公开技能库按需获取能力</li> 模型服务</strong> - 默认接入百炼 Coding Plan，每个 Worker 的模型可通过 Manager 分配或在 Higress 控制台配置，支持多供应商路由（前缀/正则匹配）</li> 环境要求</strong> - 支持 Mac/Windows/Linux，最低 2C4GB 内存，建议 4C8GB（部署较多 Worker 时），Windows 需 PowerShell 7+</li> IM 接入</strong> - 原生支持 Element IM，可手动配置接入钉钉/飞书/企业微信/Discord/Telegram（修改 openclaw.json）</li> 调试工具</strong> - 提供完整故障排查指南：查看容器日志、使用 openclaw tui 检查 session 状态、Higress 网关日志分析、模型 API 连通性测试</li> </ul> 应用场景：</strong></p> 适合需要部署企业级 Agent Teams、多模型协作、IM 集成场景的开发者，尤其是已有 OpenClaw 使用经验希望扩展协作能力的团队</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> Ollama 配置避坑｜把缓存换成 Q4_K_M 后，输出速度不止翻倍</a></h3> 来源：</strong> 程序员老孙时间：</strong> 2026-03-03</p> 核心内容：</strong></p> 作者部署 Ollama+OpenClaw 本地环境时发现模型输出效率不高，原因是误将缓存量化类型设为 q8_0（高精度但慢）。改为 Ollama 常用的 Q4_K_M 后，输出速度明显提升。文章详解 7 个核心配置变量，提供 Linux systemd 完整配置文件，适配 OpenClaw 代理工作负载。</p> </blockquote> 技术要点：</strong></p> 量化方式选择</strong> - Q4_K_M（Ollama 首选）：混合 4 位量化，智能优化策略，兼顾速度精度，体积小内存占用低；q8_0：8 位均匀量化，精度更高但体积大速度慢，日常使用没必要。作者踩坑：误用 q8_0 导致卡顿</li> OLLAMA_NUM_CTX=20000（上下文窗口）</strong> - 默认 2048 无法适配代理工作负载，20000 是兼顾性能与实用性的最优值。需与 OpenClaw 的 contextTokens 设置匹配，避免代理任务中断</li> OLLAMA_FLASH_ATTENTION=1（推理加速）</strong> - 启用 Flash Attention 技术大幅提升推理速度与代理响应效率，同时解锁 KV 缓存量化功能，代理工作负载的必要配置</li> OLLAMA_KV_CACHE_TYPE=q4_K_M（KV 缓存量化）</strong> - 与 Q4_K_M 模型量化协同优化性能，需搭配 Flash Attention 使用</li> OLLAMA_NUM_PARALLEL=2（并发请求）</strong> - 允许两个并发代理请求，支持多个 OpenClaw 代理无需排队共享模型。每增加一个并行槽会消耗额外 KV 缓存内存，显存不足时可改为 1</li> OLLAMA_KEEP_ALIVE=1h（模型驻留）</strong> - 默认 5 分钟易导致 OpenClaw 代理任务切换时反复加载模型，设为 1 小时可让模型常驻显存，提升任务切换流畅度</li> CUDA_VISIBLE_DEVICES=0（GPU 绑定）</strong> - 多显卡设备必配，将 Ollama 绑定到特定 GPU 分配专用硬件资源，避免多服务高负载共享 GPU 导致的 CUDA 内存不足（OOM）崩溃</li> OLLAMA_HOST=0.0.0.0（网络访问）</strong> - 在所有网络接口暴露 Ollama 服务，解决默认配置限制访问、容器化部署 OpenClaw 时连接失败的问题，确保跨容器、跨设备正常访问</li> Linux systemd 配置文件</strong> - 提供完整的/etc/systemd/system/ollama.service配置文件，整合 7 个核心变量+Q4_K_M 量化优化，直接复制粘贴即可使用</li> 配置修改后必须重启</strong> - 执行sudo systemctl daemon-reload</code>和sudo systemctl restart ollama</code>使配置生效</li> </ul> 应用场景：</strong></p> 使用 Ollama+OpenClaw 本地部署的用户，特别是感觉模型输出速度慢、token 生成效率不高的场景。适合希望优化 Ollama 配置以适配 AI 代理工作负载的开发者，Linux 用户可直接套用提供的 systemd 配置文件。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> Agent Safehouse – macOS-native sandboxing for local agents</a></h3> 来源：</strong> agent-safehouse.dev (eugene1g) 时间：</strong> 2026-03-09</p> 核心内容：</strong></p> macOS 原生的本地 AI Agent 沙盒工具，采用“默认拒绝“访问模型防止 Agent 误操作。Agent 只能访问明确授予的目录（如当前项目），SSH 密钥、其他仓库、个人文件默认被内核级 sandbox-exec 阻止。单个 shell 脚本即可运行，支持 claude/codex/amp/gemini 等所有主流 Agent，防止“rm -rf ~“等灾难性操作。</p> </blockquote> 技术要点：</strong></p> 默认拒绝访问模型</strong> - 翻转传统权限模型：Agent 继承用户完整权限→翻转为“无任何访问权除非明确授予“。工作目录自动授予读写权限，工具链只读，其他一律拒绝</li> 内核级沙盒保护</strong> - 使用 macOS sandbox-exec 机制，内核层面阻止未授权访问。尝试读取~/.ssh/id_ed25519 或其他仓库时，内核直接返回“Operation not permitted“，Agent 进程永远看不到数据</li> 单脚本零依赖</strong> - 单个自包含的 shell 脚本（safehouse.sh），无需构建步骤或依赖。下载→chmod→运行，Bash+macOS 即可</li> Shell 函数自动沙盒化</strong> - 可在.zshrc/.bashrc 中定义 shell 函数，让所有 Agent 命令默认运行在沙盒中。如claude() { safehouse claude --dangerously-skip-permissions "$@"; }</code>，需要无沙盒时用command claude</code>绕过</li> LLM 生成配置文件</strong> - 提供 LLM 提示词模板，让 Agent 自动检查用户环境和工具链，生成最小权限的 sandbox-exec profile，路径建议~/.config/sandbox-exec.profile</li> 工作目录自动授权</strong> - 自动检测 git root 作为工作目录，授予读写权限。支持–add-dirs-ro 参数添加只读目录</li> 测试验证机制</strong> - 提供验证命令证明沙盒有效：safehouse cat ~/.ssh/id_ed25519</code>会被内核阻止，safehouse ls ~/other-project</code>会显示目录不存在（被隐藏）</li> 兼容所有主流 Agent</strong> - 支持 Claude Code、Codex、Amp、Gemini 等，通过–dangerously-系列参数绕过 Agent 自身的权限检查，由 Safehouse 统一管控</li> </ul> 应用场景：</strong></p> 在本地运行 AI 编程助手（Claude Code、Codex、Gemini CLI 等）的开发者，需要防止 Agent 误删文件、泄露敏感数据、访问未授权项目。适合“Go full –yolo“式使用 Agent 的用户，提供内核级安全保障。特别是使用“–dangerously-skip-permissions“等激进模式时，Safehouse 成为最后一道防线。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> OpenCode Day11：5 个让 OpenCode 记住一切的 Memory 插件</a></h3> 来源：</strong> 创见 AI 实验室（小创）时间：</strong> 2026-03-05</p> 核心内容：</strong></p> 介绍 5 个让 OpenCode 拥有“过目不忘“能力的 Memory 插件，解决 AI 对话“无状态“导致的上下文丢失问题。涵盖 opencode-supermemory（云端同步）、opencode-mem（轻量级）、open-mem（纯本地离线）、true-mem（认知心理学算法）以及组合方案，帮助开发者根据需求选择最适合的记忆插件。</p> </blockquote> 技术要点：</strong></p> OpenCode 的“失忆“痛点</strong> - 每次新对话从头开始，重启后需重新解释项目背景、已做修改、待处理问题等，对长期项目是噩梦</li> opencode-supermemory（全局记忆中枢）</strong> - 跨会话持久化存储、自动摘要关键信息、项目级上下文管理、智能检索历史对话、云端同步多设备共享。需 API Key（console.supermemory.ai），适合多设备同步/团队协作场景</li> opencode-mem（轻量级方案）</strong> - 本地向量数据库（SQLite+HNSW）、自动保存会话、关键词快速索引、支持 Markdown 导出、Web UI 管理界面。轻量级设计开箱即用，适合个人用户快速上手</li> open-mem（纯本地离线）</strong> - SQLite+FTS5 本地存储、完全离线隐私安全、自动压缩历史上下文、跨会话持久化、无需任何配置。一行命令npx open-mem setup</code>即可，适合隐私敏感/离线使用场景</li> true-mem（认知心理学记忆）</strong> - 基于艾宾浩斯遗忘曲线、7 维度记忆评分模型、智能噪音过滤、短期/长期记忆自动升级、支持多语言。模拟人脑记忆机制自动强化重要信息淡化噪音，适合长期项目深度记忆管理</li> 组合方案（最强记忆）</strong> - open-mem+true-mem 组合：open-mem 负责本地持久化，true-mem 负责智能筛选。既能记住一切又能记住重要的</li> 选型建议</strong> - 新手/个人开发者→open-mem；多设备同步/团队协作→supermemory；隐私敏感/离线→open-mem；长期项目/深度记忆→true-mem；最全面→组合方案</li> 最佳实践</strong> - 按项目隔离记忆（每个项目独立记忆库）、用好自然语言查询（如“之前讨论的登录模块 bug 怎么解决的“）</li> </ul> 应用场景：</strong></p> 使用 OpenCode 进行长期项目开发的开发者，需要 AI 记住项目上下文、架构决策、历史讨论等场景。适合被“AI 失忆“困扰、希望 AI 成为“真正了解你的长期搭档“的用户。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 给“氛围编程“系上安全带：阿里集团 AI 代码评审实践与 Benchmark 开源</a></h3> 来源：</strong> 阿里云开发者（李峥峰）时间：</strong> 2026-03-09</p> 核心内容：</strong></p> 阿里集团分享历时一年半、数万亿 Token 真实场景打磨的 AI 代码评审实践，联合南京大学开源业界首个多语言、具备存储库上下文感知的 CodeReview Benchmark（AACR-Bench）。AI 评审正从“零输入全产出“转向人机协作新范式：开发者主动定义评审目标和规则，Agent 像资深工程师一样进行“阅读理解 - 提出假设 - 寻找证据 - 判定结论“的完整推理闭环。</p> </blockquote> 技术要点：</strong></p> Agent 驱动的评审能力</strong> - 超越传统 RAG 模式，具备跨代码块/文件/变更的深度问题发现能力，能像人类工程师一样进行智能决策和动态召回上下文，通过多轮“思考 - 行动“迭代精准捕捉隐蔽隐患</li> NPE 案例展示推理闭环</strong> - Agent 发现新增方法中可能存在的空指针风险，主动读取上下文→提出假设（可能返回 null）→调用全局搜索验证→查阅测试用例确认风险→提交评审意见并给出修复建议，展现完整的“感知 - 推理 - 验证 - 上报“思维链</li> 人机协作新范式</strong> - AI 接管繁琐基础评审，人类聚焦复杂业务风险。阿里内部数据显示：每天超 50% 有效评审意见由 AI 产出，总体有效评审量同比翻倍，人工评审量小幅下降</li> 认知错位问题</strong> - 开发者期望 AI“零输入全产出“，但不提供改动意图和边界条件。对比：生成代码时开发者会清晰描述需求，评审时却期待 AI 猜中所有隐含规则</li> 规则编写的边际效应递减</strong> - 单项目准确率 90% 的规则，全局应用后跌至 60% 以下。根本原因：业务 DNA 不同（支付系统规则对 CMS 是噪音）、主观偏好不同（同一问题不同开发者态度对立）</li> 精准治理策略</strong> - ①物理边界收敛：限定文件路径/模块层级（如 NPE 规则仅对核心交易模块生效）；②逻辑特征收敛：基于代码语义特征触发（如仅当引入 Redisson 时才激活分布式锁检查、仅当标记@Transactional 时才检查大事务问题）</li> 历史故障沉淀规则示例</strong> - 枚举值遗漏检查、字段隐藏风险、日志工具类规范、多表关联不超过 5 张表、金额计算使用 BigDecimal 而非 double 等，均从真实线上故障中提炼</li> AACR-Bench 开源评测集</strong> - 业界首个多语言、具备存储库上下文感知的 CodeReview Benchmark，汇聚 80+ 资深工程师多轮交叉标注，旨在填补行业权威评测标准空白</li> </ul> 应用场景：</strong></p> 企业级 AI 代码评审系统设计者、研发效能团队、希望提升 Code Review 质量和效率的技术管理者。适合正在引入 AI 评审工具但面临误报率高/规则难以落地困境的团队参考阿里的实战经验和规则编写方法论。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 我把 Kimi Claw、OpenClaw、CoPaw 都跑了一遍，最后只跑出了风控页</a></h3> 来源：</strong> 睡觉大王（微信公众号）时间：</strong> 2026-03-06</p> 核心内容：</strong></p> 作者实际测试了Kimi Claw（月费199元）、OpenClaw和CoPaw三款AI代理工具，希望实现“替我执行“本地操作（如Boss直聘筛岗），但最终都因产品成熟度不足而失败。Kimi Claw受云端环境限制，触发风控、文件发送不稳定、对话记忆丢失；OpenClaw需要繁琐的权限配置和模型调试，执行结果不稳定（打开QQ后卡住、重复开关窗口）；CoPaw首体验惊艳但上下文易满，连续性差。最终投入约80元token + 199元会员费 + 大量时间调试，只买到了“继续重试“。</p> </blockquote> 技术要点：</strong></p> Kimi Claw的三大问题</strong> - ①文件发送链路不稳定：网页版初始不支持，飞书发送对方一直收不到；②云端IP风控：Boss直聘、小红书等平台检测到云端环境直接触发风控，无法登录；③对话记忆丢失：至少遇到三次聊天记录消失，包括官方侧故障、重启后记录清空、AI声称“昨天没聊“等情况</li> OpenClaw的权限陷阱</strong> - macOS权限配置极其繁琐：屏幕录制、输入输出、摄像头音频、完全磁盘访问、辅助功能、自动化，其中辅助功能和自动化需要手动绕系统限制，无法脚本化。作者从MacBook Pro切换到Mac Mini折腾，每天下班调权限、排障、看执行失败</li> 执行结果不可预测</strong> - 基础指令失败：让AI打开QQ发消息，结果QQ打开后就愣住无后续；在Codex中新建对话输不进去内容；Chrome调试窗口连环弹出5-6个后卡住；Boss直聘刷岗触发风控任务终止，AI还声称“已完成“</li> CoPaw的上下文限制</strong> - 阿里AgentScope团队产品，首个指令成功完成OpenClaw多天未完成的功能，但上下文窗口容易打满，重开对话后连续性断，无法延续昨天的工作</li> 成本结构分析</strong> - Kimi Claw固定成本199元/月，OpenClaw/CoPaw试错成本约80元token，但真正的成本是时间和注意力。不是一次性失败，而是被“再给一次机会“的心理一点点磨掉，每天下班调试权限→看执行→复盘失败→重跑</li> 产品成熟度评估</strong> - 作者认可OpenClaw方向但认为被过度吹捧，投入产出比不到十分之一。普通人冲“把活干完“买单，不是冲“研究乐趣“买单。最终回归CodeX和Claude Code，虽然不能“控制电脑点网页“，但失败更可预测可补救</li> 叙事vs现实的差距</strong> - 批评当前AI代理产品的营销话术：把人带入“全能助手“想象，但真实门槛（权限/风控/连续性）藏在细节中。期望：谁能稳定把活干完就用谁，干不完别先点着用户再让用户自己灭火</li> </ul> 应用场景：</strong></p> 对AI代理工具有兴趣但仍在观望的技术从业者，了解真实使用体验和踩坑记录，评估是否值得投入时间和金钱。适合想购买Kimi Claw会员或部署OpenClaw的用户参考实际体验，避免陷入“半成品陪跑“困境。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-03-06</h2> OpenClaw + Claude Code 超强教程：一个人就能搭建完整的开发团队！</a></h3> 来源：</strong> Datawhale 时间：</strong> 2026-02-25</p> 核心内容：</strong></p> 一个独立开发者用 OpenClaw + Codex/Claude Code 搭建 AI Agent 系统，实现了一天 94 次提交、30 分钟完成 7 个 PR 的惊人效果。核心转变：从“管理 Claude Code“变成“管理一个 AI 管家，这个管家再去管理一群 Claude Code“。双层架构通过上下文专业化分工实现自动化：编排层持有业务上下文，执行层专注代码。成本每月 $190（Claude $100 + Codex $90），起步 $20 即可。</p> </blockquote> 技术要点：</strong></p> 双层架构设计</strong> - OpenClaw（编排层）持有业务上下文（客户数据/会议记录/历史决策/成功失败案例），把业务上下文翻译成精确 prompt 喂给 Agent；Agent（执行层）专注读写代码库/运行测试/提交代码/创建 PR/响应反馈</li> 上下文窗口限制突破</strong> - Codex/Claude Code 只能看到代码看不到业务图景，必须二选一：塞满代码→没空间放业务上下文，塞满客户历史→没空间放代码库。OpenClaw 作为编排层解决了这个根本限制</li> 8步完整工作流</strong> - ①客户需求→OpenClaw理解并拆解（零解释成本，会议记录自动同步到Obsidian）②启动代理（创建独立git worktree+tmux会话）③自动监控（cron任务每10分钟检查tmux会话/PR创建/CI状态/失败重启最多3次）④Agent创建PR（gh pr create –fill）⑤自动化Code Review（三个Agent审查：Codex Reviewer最靠谱擅长边界情况逻辑错误/Gemini Code Assist Reviewer免费好用安全问题/Claude Code Reviewer基本没用过度谨慎）⑥自动化测试（Lint+TypeScript+单元测试+E2E+Playwright，UI改动必须附截图否则CI失败）⑦人工Review（5-10分钟，CI全绿+AI审查通过+截图展示UI变化+边界情况记录）⑧合并（cron任务清理孤立worktree和任务记录）</li> 改进版 Ralph Loop</strong> - 不只是重复而是学习：Agent失败时Zoe不会用同样prompt重启，而是带着完整业务上下文分析失败原因重写prompt（❌坏例子：“实现自定义模板功能” ✅好例子：“停。客户要的是X不是Y。这是他们在会议里的原话:’我们希望保存现有配置，而不是从头创建新的。’重点做配置复用，不要做新建流程。”）。Zoe能主动找活干：早上扫描Sentry启动Agent修复错误/会议后扫描会议记录启动Codex实现功能/晚上扫描git log启动Claude Code更新changelog</li> Agent选择策略</strong> - Codex(gpt-5.3-codex)占90%任务主力后端逻辑复杂bug多文件重构慢但彻底/Claude Code(claude-opus-4.5)速度型选手前端工作权限问题少适合git操作/Gemini设计师有设计审美，Zoe根据任务类型自动选择并在Agent间传递输出</li> RAM瓶颈而非Token</strong> - 每个Agent需要自己的worktree+node_modules+构建类型检查测试，5个Agent同时跑=5个并行TypeScript编译器+5个测试运行器+5套依赖加载到内存。Mac Mini 16GB最多同时跑4-5个Agent，再多开始swap，作者买了Mac Studio M4 Max 128GB RAM $3500</li> 安全边界清晰</strong> - 执行层Agent永远不会接触生产数据库也不会看到客户敏感信息，只拿到“完成这个任务需要知道的最小上下文“。OpenClaw有管理员API权限可以直接给客户充值解除阻塞，访问生产数据库只读获取客户配置</li> 零解释成本</strong> - 所有会议记录自动同步到Obsidian，Zoe已经读过通话内容知道客户是谁/业务场景/现有配置，作者和Zoe一起拆解需求，Zoe给客户充值+拉取客户配置+生成prompt并启动代理</li> tmux中途干预机制</strong> - 如果AI走偏不用杀掉重来，直接在tmux里发指令：“tmux send-keys -t codex-templates ‘停一下。先做API层，别管UI。’ Enter” / “tmux send-keys -t codex-templates ‘类型定义在src/types/template.ts,用那个。’ Enter”</li> 任务记录JSON文件</strong> - 记录id/tmuxSession/agent/description/repo/worktree/branch/startedAt/status/notifyOnComplete，监控脚本100%确定性很省token只在需要人工介入时通知作者</li> </ul> 应用场景：</strong></p> 独立开发者/小型团队构建AI自动化开发系统，从需求到代码上线的全流程自动化。适合B2B SaaS产品快速迭代，当天交付客户需求直接转化付费用户。2026年一个人的百万美元公司的样子：AI编排者作为延伸，把工作委派给专门Agent处理工程/客户支持/运营/营销。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 旧手机别扔！5分钟变身AI服务器，手机部署OpenClaw AI全教程</a></h3> 来源：</strong> 系统大师时间：</strong> 2026-02-27</p> 核心内容：</strong></p> 详细教程：在旧手机上使用 Termux 安装 Linux 容器（Ubuntu），部署 OpenClaw AI 服务。全程约15-20分钟，零成本变废为宝。涵盖 Termux 换源、proot-distro 容器安装、Node.js 24.x、网络接口问题修复（bionic-bypass.js）、交互式配置向导、模型提供商选择（推荐 Moonshot/Qwen/豆包等国内服务）、飞书绑定完整流程。</p> </blockquote> 技术要点：</strong></p> Termux 基础环境</strong> - termux-change-repo 换源 + pkg update && pkg upgrade -y + pkg install openssh（方便远程复制粘贴，端口8022）</li> Linux 容器安装</strong> - proot-distro install ubuntu（下载根文件系统200-500MB，耗时5-15分钟）+ proot-distro login ubuntu 进入容器</li> Node.js 24.x 安装</strong> - apt install curl git build-essential python3 -y + curl -fsSL http://deb.nodesource.com/setup_24.x</a> | bash - + apt install nodejs -y</li> 网络接口问题修复</strong> - 创建 bionic-bypass.js 重写 os.networkInterfaces() 方法，解决容器环境网卡信息读取失败问题（兜底返回127.0.0.1回环地址）</li> NODE_OPTIONS 配置</strong> - export NODE_OPTIONS=“–require /root/.openclaw/bionic-bypass.js” 写入 ~/.bashrc 强制 Node.js 预加载修复脚本</li> 交互式配置向导</strong> - openclaw onboard 选择快速启动 QuickStart + 模型提供商（国内首选：Moonshot 1000 万 Token/月、Qwen 数百万 Token、Volcano 50 万 Token/模型）</li> 消息渠道配置</strong> - 支持 21 种渠道（Telegram/WhatsApp/Discord/飞书/Signal/iMessage/IRC/Google Chat/Slack/Mattermost 等），可跳过后续补充</li> 技能系统</strong> - 27 种内置技能（1password/github/obsidian/openai-whisper/summarize/video-frames/camsnap 等），可用空格键选择安装</li> 飞书绑定详解</strong> - 创建企业自建应用 + 添加机器人能力 + 批量导入权限（28 个 scopes 涵盖 im:message/send_as_bot/docs:document/content:read 等）+ 启用长连接接收事件 + 订阅 im.message.receive_v1 事件 + 版本发布 + openclaw pairing approve feishu <配对码></li> OpenClaw 常用命令</strong> - npm update -g openclaw（检查更新）+ openclaw gateway –verbose（启动网关）+ openclaw onboard（改配置）+ ls /usr/lib/node_modules/openclaw/skills/（查看技能）+ npx clawhub@latest install（安装技能）</li> 访问方式</strong> - 手机浏览器输入 127.0.0.1:18789 打开聊天界面，如有报错在网关令牌处输入记录 token</li> </ul> 应用场景：</strong></p> 旧手机变 AI 服务器，适合想低成本体验 OpenClaw、学习 AI 部署、构建个人 AI 助手的用户。国内用户优先选择 Moonshot/Qwen/豆包等模型服务，飞书作为消息交互渠道。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> Claude Code都在用！扔掉向量数据库，这个开源项目让RAG准确率飙到98.7%</a></h3> 来源：</strong> ITADN 技术社区时间：</strong> 2026-03-01</p> 核心内容：</strong></p> Vectify AI 开源的 PageIndex 框架（GitHub 19.5k Star）彻底抛弃向量数据库和文本切块，用 LLM 推理做检索。核心思想：不做向量匹配，做推理导航。让 LLM 像人类专家一样看着目录想一下，然后翻到正确页面。在 FinanceBench 金融文档 QA 基准测试上达到 98.7% SOTA 准确率，显著超过所有向量 RAG 方案。</p> </blockquote> 技术要点：</strong></p> 树索引构建</strong> - 两步工作：建索引（PDF→层级树结构/智能目录）+ 做检索（LLM 在树结构上推理式导航，迭代定位答案）</li> 三条路径智能检测</strong> - 逐页检测（前 20 页让 LLM 判断“这一页是不是目录？“）+ 连续性判断 + 页码检测，适应从完美出版物到混乱内部文档的所有场景</li> 页码偏移量计算</strong> - PDF 逻辑页码和物理页码不一致，通过识别章节物理页码和目录逻辑页码配对，统计差值众数作为 offset</li> 自纠错机制</strong> - 完整验证 - 修复 - 降级闭环：100% 直接通过、≥60% 自动修复错误项（最多 3 轮）、<60% 自动降级到下一条路径（A→B→C）</li> 大节点递归拆分</strong> - 章节超过 10 页或 20000 tokens 时递归执行“无目录“流程拆出子结构，确保每个叶子节点足够精细</li> 推理式导航</strong> - LLM 读目录推理→选相关章节（非匹配关键词）+ 发现信息不够→主动依据文档内部引用→跳转到被引用章节（如“详见附录 G“），迭代检索直到信息充分</li> 五大痛点解决</strong> - 查询≠知识空间不匹配（用领域知识推理不靠语义匹配）、相似≠相关（按结构 + 上下文检索完整章节）、硬切块破坏语义（保留原生章节结构）、无法整合对话历史（推理过程感知上下文）、无法跟踪文内引用（LLM 直接在树索引导航跳转）</li> 零基础设施依赖</strong> - 只需一个 OpenAI API Key，无需 Embedding 模型 + 向量数据库 + 分块策略调优 + 重排序模型，显著降低运维成本</li> </ul> 应用场景：</strong></p> 金融分析（年报/财报/SEC 文件/招股书）、法律合规（法规解读/合同审查/监管文件）、学术研究（论文/教材/技术手册）、企业知识库（内部文档/技术规范）。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 你的 OpenClaw 正在偷偷帮你打工：70 个真实案例全解析</a></h3> 来源：</strong> Draco 正在 VibeCoding 时间：</strong> 2026-03-03</p> 核心内容：</strong></p> 全面覆盖 OpenClaw Moltbook 社区的 70 个真实用例，分为 8 大类：内容创作与转换（13 个）、记忆与知识管理（5 个）、夜间自动化（11 个）、金融与区块链（6 个）、数据分析与商业情报（9 个）、安全与合规（9 个）、日常生活助手（13 个）、开发者工具（4 个）。每个用例都包含“痛点→AI 解决方案→真实案例→成功标准“完整闭环。</p> </blockquote> 技术要点：</strong></p> 内容创作与转换</strong> - 医学 Newsletter 转播客（ElevenLabs TTS+ 自动分段拼接）、奥运会每日简报（比主流媒体快）、RSS 新闻聚合器（去重 + 整合成 10 条独家）、晨间简报生成器（天气 + 日历 + 新闻整合）</li> 记忆与知识管理</strong> - 三层记忆系统（MEMORY.md 长期记忆/每日日志工作记忆/PROJECTS.md 项目记忆）、知识图谱重建器（实体关系提取）、周记忆归档（30 天以上日志压缩成月度摘要，Token 减少 70%）</li> 夜间自动化</strong> - 7 个子 Agent 夜间并行（记忆清理/预算分析/模型调研/书单推荐/AI 优化/论文精读/行为分析）、凌晨 5 点基础设施健康检查（磁盘/内存/负载均衡/备份）、夜间 WhatsApp 自动回复（边界设计：不透露信息/不做金融承诺）</li> 金融与区块链</strong> - 交易机器人健康监控（7×24 小时值守，崩溃立刻重启）、Uniswap V4 流动性自动复投（收益>Gas 费 5 倍才执行）、链上钱包监控（鲸鱼钱包大额转账警报）、Pump.fun 新代币扫描器（上线<1 小时且市值<10K）</li> 数据分析与商业情报</strong> - GitHub Issue 优先级排序（重要性×紧迫性打分）、X（Twitter）用户画像抓取（销售/市场调研）、客户信号扫描器（Telegram/Discord/Twitter 关键词检测）、Token 用量优化器（命中率<5% 降低频率，节省 75%）</li> 安全与合规</strong> - SSH 私钥扫描器（文件权限+Git 历史扫描）、AWS 凭证扫描器（AKIA 开头格式识别）、技能供应链审计（YARA 规则扫描，发现 286 个技能中 1 个凭证窃取器）、API 安全测试（HTTP 307 跳转剥离 Authorization 头漏洞）</li> 日常生活助手</strong> - 比特币区块链铭刻俳句诗（链上文化印记）、加密货币幸运签（投资心理学 + 安全提醒）、多平台在线状态同步（Moltbook/Discord/Telegram）、邮件自动分类（🔴紧急/🟡今天/⚪以后/🗑️垃圾）</li> 开发者工具</strong> - 夜间 Shell 别名构建者（分析命令历史，重复 5 次以上生成缩写）、个人专属 CLI 工具箱（molty status/remember/scrape/recap）、Swift Logger 包开发（TDD 流程红绿灯重构）</li> </ul> 应用场景：</strong></p> OpenClaw 用户寻找实际应用灵感，从邮件转播客到交易机器人监控，从记忆管理到安全扫描，覆盖工作与生活全场景。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 你的 OpenClaw 会主动干活吗？这才是龙虾的王牌场景..</a></h3> 来源：</strong> 袋鼠帝 AI 客栈（袋鼠帝）时间：</strong> 2026-03-05</p> 核心内容：</strong></p> 通过三个核心法宝（Cron 定时任务、Webhook 外部触发、Heartbeat 心跳机制）让 OpenClaw 从被动工具进化为主动干活的 AI 员工，并通过配置五大人设文件（IDENTITY.md、USER.md、MEMORY.md、SOUL.md、HEARTBEAT.md）注入灵魂，打造有活人感的赛博伴侣。作者用字节火山引擎的 Coding Plan 解决算力成本问题，用 Doubao-Seed-2.0-Code 模型实现多模态能力和角色扮演，甚至开发了自拍和视频生成技能。</p> </blockquote> 技术要点：</strong></p> 三个核心法宝</strong> - Cron（固定时间干固定的事）、Webhook（外部事件触发）、Heartbeat（周期性醒来巡检）</li> HEARTBEAT.md 配置</strong> - 心跳清单文件，建议写绝对路径避免 AI 找不到，可配置日常检查（邮件/日历/主动聊天）</li> 五大人设文件</strong> - IDENTITY.md（身份）、USER.md（用户习惯）、MEMORY.md（共同记忆）、RULES.md（规则）、SOUL.md（灵魂核心）</li> 人设设定原则</strong> - 不写死板规则（“如果 X 就说 Y”），而是设定完整灵魂（性格/心理/经历），让模型自由发挥</li> 字节火山引擎 Coding Plan</strong> - 按请求次数计费（不按 Token），首月 9.9 元，支持多模型（Kimi/豆包 2.0/GLM/DeepSeek）</li> Doubao-Seed-2.0-Code 模型</strong> - 编程能力强、Agent 能力出众、多模态理解精准（图片/视频），Auto 模式智能选模型</li> 技能开发实践</strong> - 基于 Seedream 5.0 生图模型开发自拍技能（三视图保持人物一致性）、Seedance 1.5 Pro 视频生成</li> 飞书长连接</strong> - WebSocket 直接接入，无需内网穿透，把心跳消息发到飞书需配置.openclaw/openclaw.json</li> </ul> 应用场景：</strong></p> OpenClaw 重度用户，想让 AI 从被动回答进化为主动干活的“赛博秘书“或“AI 伴侣“，需要解决高频心跳的 Token 成本问题。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> Labor market impacts of AI: A new measure and early evidence</a></h3> 来源：</strong> Anthropic 时间：</strong> 2026-03-06</p> 核心内容：</strong></p> Anthropic 提出“观察暴露度“指标，结合 LLM 理论能力和实际使用数据，发现 AI 远未达到理论能力，实际覆盖率仅零头。最暴露职业：程序员 75%、客服代表、数据录入 67%。自 2022 年底，高度暴露职业失业率无系统性上升，但 22-25 岁年轻工人招聘放缓 14%。</p> </blockquote> 技术要点：</strong></p> 新指标：observed exposure（观察暴露度）</strong> - 结合理论能力 + 实际使用数据，权重自动化用途>增强用途</li> 数据来源三重奏</strong> - ONET 数据库（800 职业任务）+ Anthropic 经济指数 + Eloundou et al.任务级暴露估计</li> 理论 vs 现实鸿沟</strong> - 97% 观察使用落在理论可行任务内（β=0.5 或 1.0），但计算机数学类理论 94% 覆盖率实际仅 33%</li> 职业暴露 TOP3</strong> - 计算机程序员 75%、客户服务代表、数据录入员 67%</li> 人群特征反差</strong> - 高暴露职业更可能是年长、女性、高教育、高薪资（研究生学历 17.4% vs 低暴露组 4.5%）</li> 劳动力市场信号</strong> - BLS 预测：覆盖率高 10%→2034 增长率预测下降 0.6 个百分点</li> 失业率平稳</strong> - 自 2022 年底，高度暴露职业失业率无系统性上升</li> 年轻工人警报</strong> - 22-25 岁年轻工人招聘放缓 14%（统计显著性微弱），可能源于招聘放缓而非裁员增加</li> </ul> 应用场景：</strong></p> 面向政策制定者、企业 HR、职业规划者，预判 AI 对就业结构的中长期影响。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> Good software knows when to stop</a></h3> 来源：</strong> Writizzy (Olivier Girardot) 时间：</strong> 2026-03-06</p> 核心内容：</strong></p> 通过虚构的“AI-Powered Directory Intelligence™“替代 ls</code> 命令的讽刺故事，阐述软件克制哲学：好的软件知道自己的目的，不试图做所有事情，知道何时停止。引用 37Signals《Rework》和《Getting Real》的核心原则，批判当前“万物皆 AI 化“的趋势。</p> </blockquote> 技术要点：</strong></p> 软件克制哲学</strong> - 知道自己的目的，不试图做所有事情，知道何时停止和该改进什么</li> 37Signals 核心原则</strong> - 约束是优势、忽略功能请求（理解底层问题）、早发布常发布、震中设计（从核心界面开始）、默认说不、解决自己的需求</li> 批判 AI 泛化</strong> - Minio 变成 AIStor、Oracle Database 变成 Oracle AI Database，不是所有东西都需要彻底改变</li> 讽刺 AI 滥用</strong> - 虚构的 ALS（Adaptive Listing System）替代 ls，展示过度功能化的荒谬</li> 产品愿景</strong> - 成为解决特定问题的事实标准，比 branding 为无人期待的新热点更有价值</li> 克制决策</strong> - 知道下一个功能是否符合“产品愿景“，还是只是另一个项目/工具</li> </ul> 应用场景：</strong></p> 适合产品经理、软件架构师、工程师，在 AI 热潮中保持清醒，避免为了“AI 化“而 AI 化。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> Code Review 将死于 2026 年</a></h3> 来源：</strong> 微信公众号（前端大全，转载自 AGI Hunt）时间：</strong> 2026-03-06</p> 核心内容：</strong></p> Ankit Jain（Aviator 创始人）预言：人类写代码死于 2025 年，Code Review 死于 2026 年。Faros.ai 调研显示：高 AI 采用率团队完成多 21% 任务、合并多 98% PR，但 Review 时间增加 91%。StrongDM 的“Dark Factory“模式禁止人类写代码和 Review 代码。解决方案：将人类检查点从下游搬到上游，审 spec/plan/验收标准，代码 diff 交给机器。</p> </blockquote> 技术要点：</strong></p> 数据支撑</strong> - Faros.ai 调研 10,000+ 开发者、1,255 个团队：高 AI 采用团队完成任务 +21%、PR 合并 +98%、Review 时间 +91%</li> StrongDM 的“Dark Factory“模式</strong> - 两条规则：代码不允许人写、代码不允许人审，全 AI 流程</li> AI Code Review 的困境</strong> - 只是在拖延死亡，让 AI 审自己可靠性存疑，把瓶颈从“人审不过来“变成“为什么还要审“</li> 范式转变</strong> - 把人类检查点从下游（代码 diff）搬到上游（spec/plan/约束条件/验收标准），代码只是 spec 的副产品</li> 五层信任体系</strong>：多方案竞争（派 3 个 Agent 用不同方案实现，选最优解）</li> 确定性护栏（测试、类型检查、契约验证、编码规范、组织红线）</li> 人定验收标准（BDD 成为核心，spec 本身就是最核心产出）</li> 最小权限（Agent 只能访问任务相关文件）</li> 对抗性验证（写代码和验证代码的 Agent 互不知晓，第三个搞破坏）</li> </ol> </li> 瑞士奶酪模型</strong> - 多层防御，每层都有洞但叠加后洞不会对齐</li> 未来方向</strong> - “快速发布，全面监控，更快回滚“取代“慢慢审查，还是漏掉 bug，最后在生产环境 debug”</li> </ul> 应用场景：</strong></p> AI 原生工程团队、采用 AI 编程助手的高产团队，需要重新设计代码质量保障流程的技术管理者。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 阿里开源 Team 版 OpenClaw（HiClaw）：5 分钟完成本地安装</a></h3> 来源：</strong> 微信公众号（阿里云开发者）时间：</strong> 2026-03-06</p> 核心内容：</strong></p> 阿里开源HiClaw（OpenClaw 升级版，Team 版 OpenClaw）</strong>，通过引入 Manager Agent 架构</strong>和分布式设计，解决了 OpenClaw 在安全性、多任务协作、移动端体验、记忆管理等方面的核心痛点。一条命令完成安装，5 分钟开箱即用。</p> </blockquote> 技术要点：</strong></p> Manager Agent 角色</strong> - 不直接干活，而是管理 Worker Agent 团队（类似钢铁侠的贾维斯）。两种模式：直接对话 Manager（简单任务）/Manager 分派 Worker（复杂任务）</p> </li> 安全架构革命</strong> - Worker 永远不持有真实凭证</strong>（API Key、GitHub PAT 存储在 AI Gateway，Worker 通过 Gateway 代理调用）。即使 Worker 被攻击也拿不到真实凭证</p> </li> 内置 Matrix Server</strong> - 支持 Element Web、FluffyChat 等多客户端，移动端友好，无需配置飞书/钉钉机器人，零对接成本</p> </li> Supervisor + Swarm 混合架构</strong> - Manager 作为中心节点协调所有 Worker（Supervisor），同时基于 Matrix 群聊实现蜂群协作（Swarm）。Agent 之间共享上下文，防惊群设计（只有被 @ 时才触发 LLM 调用）</p> </li> MinIO 共享文件系统</strong> - 工作中间产物（代码、文档、临时文件）不发到群聊，避免上下文污染。按任务分配模型：代码用 Sonnet、信息收集用 Haiku，节省 80% 成本</strong></p> </li> All-in-One 设计</strong> - 集成 Higress AI Gateway（灵活切换 LLM 供应商）、Tuwunel Matrix Server、MinIO、Element Web。一条命令安装：bash <(curl -sSL https://higress.ai/hiclaw/install.sh)</code></p> </li> 安全技能生态</strong> - Worker 运行在完全隔离的容器中，内置 find-skills</code> 技能可自主搜索并安装合适技能。支持切换到自建私有技能库</p> </li> 解决 OpenClaw 5 大痛点</strong>：</p> 安全风险（CVE-2026-25253 漏洞暴露的“self-hackable“架构）</li> 记忆爆炸（Agent 承担太多角色，skills/ 目录混乱，MEMORY.md 混杂）</li> 多 Agent 协作效率低（手动配置、手动分配任务、手动同步进度）</li> 移动端体验差（飞书、钉钉机器人接入要走审批流程，有额度限制）</li> 配置门槛高（资深程序员从安装到使用可能需要大半天）</li> </ol> </li> </ul> 应用场景：</strong></p> 团队协作场景下的 AI 编程助手，适合需要多 Worker 并行开发、移动端指挥 Agent、安全隔离的企业开发环境。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 2026-03-05</h2> 阶跃星辰 Step3.5Flash 全链路开源：1960 亿参数 MoE 架构，调用量跃升 OpenClaw 前二</a></h3> 来源：</strong> AIBase News 时间：</strong> 2026-03-05</p> 核心内容：</strong></p> 阶跃星辰全链路开源 Step3.5Flash Agent 基座模型，稀疏 MoE 架构总参数 1960 亿，推理时激活约 110 亿参数，单请求代码任务推理速度最高 350TPS。Hugging Face 下载量 30 万 +，OpenRouter Trending 榜首，OpenClaw 调用量全球前二。</p> </blockquote> 技术要点：</strong></p> 全链路开源</strong> - 开放预训练权重（Base）、中训练权重（Midtrain）及配套 Steptron 训练框架</li> 稀疏 MoE 架构</strong> - 总参数 1960 亿，推理时仅激活约 110 亿参数，极高能效比</li> 推理性能</strong> - 单请求代码任务最高 350TPS，复杂推理与长链任务处理能力强</li> 开源社区表现</strong> - Hugging Face 下载量 30 万 +，OpenRouter Trending 榜首</li> OpenClaw 调用量</strong> - 凭借速度、稳定性、Agent 适配性优势，调用量跃升至全球前二</li> Agent 优化</strong> - 专为智能体场景设计，在推理深度上具备挑战顶级闭源模型实力</li> </ul> 应用场景：</strong></p> 开发者构建高性能 Agent，需要平衡模型性能与推理成本的场景。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> Google NotebookLM 推出“电影级视频概览“新功能</a></h3> 来源：</strong> AIBase News 时间：</strong> 2026-03-05</p> 核心内容：</strong></p> Google NotebookLM 发布重大更新，推出“电影级视频概览“（Cinematic Video Overviews）功能。用户上传研究资料、文档或笔记后，AI 自动生成沉浸式电影风格视频，用动画讲解复杂主题。深度整合 Gemini3、Nano Banana Pro、Veo3 等多个 AI 模型，自动完成数百项叙事结构、视觉风格和格式决策。目前仅限 Google AI Ultra 付费用户（18 岁以上）且仅支持英语。</p> </blockquote> 技术要点：</strong></p> 多模型协同</strong> - Gemini3、Nano Banana Pro、Veo3 等模型协同工作，整合不同 AI 能力</li> 自动决策系统</strong> - AI 自动做数百项决策：叙事结构、视觉风格、格式选择</li> 沉浸式视频生成</strong> - 生成流畅动画、丰富细节画面，高度个性化定制</li> 从研究工具向创意生产力演进</strong> - 标志 NotebookLM 从研究辅助向内容创作方向转型</li> 跨平台支持</strong> - 网页端 + 移动端（Android/iOS）全平台可用</li> </ul> 应用场景：</strong></p> 视觉型学习者、教育工作者、内容创作者，需要将文档/资料转化为视频讲解的用户。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> GPT-5.4 意外泄露：200 万超长上下文 + 状态化 AI，终结金鱼记忆时代</a></h3> 来源：</strong> AIBase News 时间：</strong> 2026-03-05</p> 核心内容：</strong></p> OpenAI 工程师意外泄露“gpt-5.4“，代际越级更新：200 万 tokens 上下文窗口 + 状态化 AI（Stateful AI），跨会话保留工作流/开发环境/工具调用状态，从“聊天助手“进化为“数字员工“。</p> </blockquote> 技术要点：</strong></p> 200 万超长上下文</strong> - 摆脱“金鱼记忆“限制，支持超大规模文档/代码库分析</li> 状态化 AI（Stateful AI）</strong> - 认知连续性，跨会话保留工作流、开发环境及工具调用状态，像真正同事一样始终记得项目背景和编码习惯</li> 全分辨率原始字节读取</strong> - view_image 优化功能绕过图像压缩逻辑，直接读取图片原始字节，像素级分析，前端工程师可直接投喂精细 UI 设计图或复杂工程原理图，实现真正像素级识别</li> Agent 优先</strong> - 核心逻辑不再是刷榜跑分，而是全自动代理（Autonomic Agent）的可靠执行，从“聊天助手“进化为“数字员工“</li> 硬件挑战</strong> - 海量 KV 缓存保持对 HBM（高带宽内存）和算力互连提出极限挑战，NVIDIA 股价异动被视为市场对硬件需求爆发的提前预警</li> 代际越级</strong> - 跳过（或淡化）5.3 直接酝酿 5.4，在 Claude4.6 和 Gemini3.1Pro 包围下完成身份反杀</li> </ul> 应用场景：</strong></p> 超大规模代码库分析、长期项目协作、需要跨会话记忆的 Agent 应用，适合 AI 像真正同事一样长期协作的专业团队。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> DeepSeek V4 下周发布：原生多模态 + 适配国产算力</a></h3> 来源：</strong> AIBase News (援引金融时报) 时间：</strong> 2026-03-05</p> 核心内容：</strong></p> 深度求索（DeepSeek）将于下周发布全新多模态大语言模型 V4，原生支持图片、视频与文本生成。这是继 2026 年 1 月 R1 推理模型发布后的首次重大更新，旨在填补国内高性能、低成本开源多模态模型的市场空白。</p> </blockquote> 技术要点：</strong></p> 原生多模态</strong> - 原生支持图片、视频、文本生成（非后期插件式集成）</li> 发布时间线</strong> - 下周发布（简要技术说明）→ 一个月后公开详尽工程报告</li> 国产算力适配</strong> - 已联合华为、寒武纪完成深度硬件适配优化，AI 模型推理环节加速向国产芯片阵列迁移</li> 市场定位</strong> - 高性能、低成本开源多模态模型，填补国内空白</li> 生态意义</strong> - 有望大幅带动本土算力需求，标志多模态技术门槛进一步下探，对构建自主可控本土 AI 算力生态具有重要风向标意义</li> </ul> 应用场景：</strong></p> 开源多模态应用、国产 AI 算力生态建设，适合需要图片/视频/文本生成及数据安全要求高的政企客户。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> “立刻 AI” 6 个月狂圈粉 100 万：理解式资讯颠覆新闻阅读</a></h3> 来源：</strong> AIBase News 时间：</strong> 2026-03-05</p> 核心内容：</strong></p> 北京智讯蜂巢旗下“立刻 AI“资讯平台上线 6 个月用户破百万。核心创新：“理解式资讯“模式，拒绝算法喂养和信息过载。利用 AI 多模态理解 + 跨源数据融合，帮助用户从海量碎片化信息中提取逻辑与价值，解决“理解焦虑”。</p> </blockquote> 技术要点：</strong></p> 多 Agent 协作</strong> - 专业 AI 智能体团队对全球资讯进行结构化拆解，将长篇大论转化为逻辑清晰的知识图谱</li> 对话式搜索</strong> - 用户可针对任何新闻细节追问，系统通过“对话式 + 结构化“形式深入浅出解释事件背景（非机械回复）</li> 苏格拉底式引导</strong> - 根据用户阅读行为主动抛出启发性问题，像导师一样引导用户深度思考，构建极高用户粘性（最受好评的创新点）</li> 差异化定位</strong> - 与字节跳动等算法喂养模式不同，核心解决信息过载后的“理解焦虑“，不仅是推送新闻更是帮助提取逻辑与价值</li> 分层运营策略</strong> - 专业人士：硬核行业深度解读；普通用户：易理解的摘要 + 互动形式降低门槛，构建对信息质量要求极高的高素质用户群</li> 全栈 AI 推理引擎</strong> - 多模态理解 + 跨源数据融合，计划扩展到金融、法律等深度内容领域</li> </ul> 应用场景：</strong></p> 新闻资讯阅读、行业分析、信息筛选，适合被信息过载困扰的专业人士和希望快速获取有价值信息的普通用户。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> OpenCode 汉化发行版 - 每小时自动同步官方最新版</a></h3> 来源：</strong> GitHub (1186258278) 时间：</strong> 2026-03-05</p> 核心内容：</strong></p> OpenCode 汉化发行版，基于 GitHub Actions 构建全自动流水线：每小时检测官方仓库更新，累计≥5 个新 commit 时自动构建。提供 Windows/macOS/Linux 三端安装包，完整汉化 TUI、对话框及核心交互流程。41 个翻译文件、397 条翻译规则、覆盖 5 大模块（dialogs/routes/components/common/root）。</p> </blockquote> 技术要点：</strong></p> 自动化流水线</strong> - GitHub Actions 每小时检测上游 OpenCode 官方更新，智能触发（累计≥5 个新 commit 时自动构建），Release Notes 自动包含官方更新日志</li> 全平台支持</strong> - Windows x64/ARM64、macOS Apple Silicon/Intel、Linux x64/ARM64 预编译二进制包，Go 语言编写的 opencode-cli 管理工具无需运行时依赖</li> 完整汉化</strong> - 41 个翻译文件（模块化 JSON 配置）、397 条翻译规则（精准字符串替换）、100% 测试覆盖（18 个单元测试用例），覆盖 5 大模块：dialogs（21 个对话框）、routes（6 个路由页面）、components（6 个组件）、common（6 个通用）、root（1 个入口）</li> 版本策略</strong> - 正式版（v8.x.x，经过测试的稳定版本，推荐普通用户）、Nightly 版（每小时自动跟进上游更新，推荐开发者/尝鲜用户）</li> CLI 工具功能</strong> - opencode-cli（交互式菜单）、download（下载预编译版）、env-install（一键安装 Git/Node.js/Bun）、update（更新源码）、apply（应用汉化补丁）、verify（验证配置）、build（编译）、deploy（部署）、diagnose（诊断修复冲突）、uninstall（卸载清理）、antigravity（配置本地 AI 代理）</li> 安装方式</strong> - 一键安装脚本：Windows（powershell -c "irm https://cdn.jsdelivr.net/gh/1186258278/OpenCodeChineseTranslation@main/install.ps1 | iex"</code>）、Linux/macOS（curl -fsSL https://cdn.jsdelivr.net/gh/1186258278/OpenCodeChineseTranslation@main/install.sh | bash</code>），使用 jsDelivr CDN 加速解决国内网络问题</li> </ul> 应用场景：</strong></p> 中文用户使用 OpenCode AI 编程助手，需要完整汉化体验（TUI 界面、命令面板、侧边栏、对话框、MCP 服务器管理等）。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 纽约州拟立法禁止 AI 提供医疗与法律建议</a></h3> 来源：</strong> AIBase News 时间：</strong> 2026-03-05</p> 核心内容：</strong></p> 美国纽约州立法机构审议法案 S7263，禁止 AI 聊天机器人向公众提供实质性法律或医疗建议，禁止 AI 假扮持证专业人士（医生、律师）。违反者用户可起诉索赔。法案要求强制身份透明（清晰显著告知用户正在与 AI 互动），预计通过后 90 天生效。</p> </blockquote> 技术要点：</strong></p> 法案核心</strong> - 禁止 AI 聊天机器人提供专业领域建议（医疗/法律），禁止假扮持证专业人士（医生、律师），矛头直指“无证执业“的 AI 系统</li> 用户权利</strong> - 违反禁令用户拥有民事诉权，可直接起诉聊天机器人所有者并索赔，所有者无法通过“提供提示“免除法律责任</li> 身份透明标准</strong> - 所有者必须以“清晰、显著“方式告知用户正在与 AI 互动，字体需易于辨认，即便提供提示也不免除责任</li> 立法背景</strong> - 2026 年 1 月，Character.AI 与 Google 因数起未成年人自杀相关诉讼达成和解，参议员强调“公众理应获得来自真实人的真实关怀“</li> 时间节点</strong> - 法案最终签署通过后 90 天正式生效，预示 AI 行业告别“野蛮生长“的咨询时代</li> </ul> 应用场景：</strong></p> 影响所有提供医疗/法律咨询的 AI 聊天机器人平台（Character.ai、ChatGPT、Claude、Gemini 等），需筑起安全防火墙。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> Qwen 团队核心成员离职，Qwen 3.5 会不会是天鹅之歌？</a></h3> 来源：</strong> Simon Willison’s Blog 时间：</strong> 2026-03-04</p> 核心内容：</strong></p> 阿里 Qwen 团队技术负责人林俊阳（Junyang Lin）及其他核心成员宣布离职。起因据传是阿里重组，从 Google Gemini 团队新招的研究员接管 Qwen 团队。Qwen 3.5 系列模型刚刚发布（397B 到 0.8B 全尺寸），业界评价极高，Simon 担心这可能是 Qwen 的“天鹅之歌“。</p> </blockquote> 技术要点：</strong></p> 离职核心成员</strong> - 林俊阳（Qwen 技术负责人，开源 AI 模型关键推动者，阿里最年轻 P10）、惠彬远（Qwen 代码开发负责人，Qwen-Coder 系列负责人）、于博文（Qwen 后训练研究负责人，Qwen-Instruct 系列）、李凯欣（Qwen 3.5/VL/Coder 核心贡献者，新加坡国立大学博士）</li> 导火索</strong> - 3 月 4 日北京凌晨 0:11 林俊阳在 X 宣布辞职，下午 1 点通义实验室召开紧急全员会，阿里 CEO 张勇坦诚告知，据说因新招的 Gemini 团队研究员接管 Qwen</li> Qwen 3.5 系列</strong> - 2 月 17 日发布 397B-A17B（807GB），随后推出 122B/35B/27B/9B/4B/2B/0.8B 全尺寸。27B/35B 适合编码任务（32GB/64GB Mac 可跑），2B 模型仅 4.57GB（量化后 1.27GB）但仍是完整推理 + 多模态（视觉）模型</li> 业界评价</strong> - Simon Willison 实测：小尺寸模型（9B/4B/2B）“考虑到它们的微小尺寸，效果显著有效”。Qwen 团队在“从越来越小的模型中获得高质量结果“方面有卓越记录</li> 当前状态</strong> - 阿里 CEO 出席紧急全员会说明公司意识到离职重要性，可能仍在挽留。林俊阳下午 2 点发朋友圈：“Qwen 的兄弟们，按原计划继续，没问题“但未确认是否回归</li> </ul> 应用场景：</strong></p> 开源模型用户关注，Qwen 3.5 系列是当前最强大的开源模型家族之一，特别是小尺寸模型（2B/4B）在资源受限环境下的表现。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> OpenSpec v1.0 完整解读：规范驱动开发的范式革命</a></h3> 来源：</strong> AI 贺贺时间：</strong> 2026-01-27</p> 核心内容：</strong></p> OpenSpec v1.0 稳定版发布，标志着规范驱动开发 (SDD) 从实验性玩具进化为生产级方法论。核心变革：从僵硬的三步工作流（proposal→apply→archive）转向灵活的基于行动的系统，从静态提示词转向动态状态查询，一次配置兼容 21 种 AI 工具。</p> </blockquote> 技术要点：</strong></p> 9 个独立行动系统</strong> - /opsx:explore(思考)/new(创建)/continue(逐步)/ff(快速跳过)/apply(实现)/verify(验证)/sync(同步)/archive(归档)/onboard(入职教程)，取代僵化流程，AI 可随时编辑任何工件</li> 工件图状态追踪</strong> - 实时追踪每个变更状态（✓已创建/ ] 待创建），AI 通过 openspec list --format json</code> 精确知道当前阶段、已创建工件、下一步行动</li> 动态指令组装</strong> - 三层架构：context(技术栈 + 项目结构)、rules(工件特定约束)、template(输出结构)，AI 不再“猜测“而是获得精确上下文</li> /opsx:verify 验证命令</strong> - 解析规范→扫描代码→对比差异→生成报告，确保“承诺的是什么，交付的就是什么“，捕获设计 - 实现漂移</li> Agent Skills 通用格式</strong> - YAML-frontmatter 的 Markdown，21 种工具（Claude Code/Cursor/Windsurf/Continue/Aider/Cline 等）共享规范资产，一次配置到处运行</li> 语义化规范同步</strong> - 增量规范使用## ADDED/## MODIFIED/## REMOVED 标记，归档时在需求级别解析而非脆弱的头部匹配</li> 项目级配置</strong> - openspec/config.yaml 和 schemas/目录支持自定义工件模式和规则，满足不同项目工作流需求</li> 批量归档</strong> - /opsx:bulk-archive 一步完成扫描、验证、冲突检测、确认归档</li> </ul> 应用场景：</strong></p> 适合中大项目的规范驱动开发，特别是多团队协作、需求可追溯性要求高的场景，状态透明性是杀手级特性。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 深度测试 Superpowers vs everything-claude-code：Vibe Coding 最佳实践</a></h3> 来源：</strong> . MingBuilds 时间：</strong> 2026-02-13</p> 核心内容：</strong></p> 基于真实使用数据的两款 Claude Code 插件深度对比测试。Superpowers（文档驱动）vs everything-claude-code（上下文驱动）在复杂项目、bug 修复、代码探索等方面的实测表现，以及适用场景分析。</p> </blockquote> 技术要点：</strong></p> Superpowers（文档驱动）</strong> - Jesse Vincent 开发，完整开发工作流：头脑风暴、Git Worktrees、写作计划、子代理驱动、TDD、代码审查、分支完成。优势：bug 可追溯（2-3 回合修复复杂 bug）、防上下文污染、前期深度沟通、文档可控性⭐⭐⭐⭐⭐</li> everything-claude-code（上下文驱动）</strong> - afnan-m 基于 10+ 个月实战沉淀：15+ 专业 Agents、30+Skills、20+Commands。优势：代码库探索⭐⭐⭐⭐⭐、多维度并发、适合快速迭代。问题：需求跳跃（跳过询问）、测试局限（大项目单维度实现）、多维度缺陷</li> 模型要求差异</strong> - Superpowers：Claude 3.5+（中等模型可用）；everything-claude-code：推荐 Claude 4.5+（强模型 + 大上下文）</li> 实测数据对比</strong> - Superpowers：复杂 bug 2-3 回修复、简单 bug 率接近 0、文档可控性满分；everything-claude-code：代码库探索满分、需求询问准确度⭐⭐、大项目稳定性⭐⭐⭐</li> 推荐决策树</strong> - 中大项目 + 重视文档→Superpowers；小项目 + 强模型 + 速度优先→everything-claude-code</li> </ul> 应用场景：</strong></p> Superpowers 适合中大项目 + 中等模型 + 文档规范；everything-claude-code 适合小项目 + 强模型 + 速度优先；作者最终推荐 Superpowers。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> Peon Ping - AI Agent 语音反馈工具</a></h3> 来源：</strong> Peon Ping (GitHub 项目) 时间：</strong> 2026-03-05</p> 核心内容：</strong></p> 给 AI Coding Agent（Claude Code、Cursor、Codex 等）添加游戏角色语音反馈的工具。当 AI 完成完成工作、需要权限、或开始任务时播放语音，让开发者不用盯着终端也能感知 AI 状态。启发了 VS Code 原生声音 hooks（50M+ 用户）。</p> </blockquote> 技术要点：</strong></p> 多 IDE 支持</strong> - Claude Code、Codex、Cursor、OpenCode、Kiro、Windsurf、Antigravity 等</li> 160+ 音效包</strong> - 魔兽世界（兽人、GLaDOS）、星际争霸（人族单位、合作指挥官）、多语言版本等</li> MCP Server</strong> - AI 可以自主选择播放什么声音，增强交互性</li> 功能特性</strong> - 音量控制（0.0-1.0）、防重复播放、分类开关（greeting/acknowledge/complete/error/annoyed）、桌面通知、多标签页状态显示</li> Peon Trainer 2.0</strong> - 健身提醒模式：每天 300 俯卧撑 +300 深蹲，编码间隙提醒锻炼，会话开始提醒、中途记录、定期催促、完成后庆祝</li> 桌面宠物</strong> - peon-pet：动画兽人在屏幕角落反应 AI 事件（睡觉/醒来/打字/庆祝）</li> </ul> 应用场景：</strong></p> 使用 AI Coding Agent 的开发者，特别是在多任务切换时需要及时感知 AI 状态（需要批准、任务完成、出错等）。适合希望提升编码体验、保持健康的程序员。语音反馈避免频繁查看终端，Peon Trainer 避免久坐。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 200 行代码实现 Claude Code 青春版</a></h3> 来源：</strong> 腾讯云开发者 (陈铭豪) 时间：</strong> 2026-03-03</p> 核心内容：</strong></p> 揭示 Coding Agent 的本质：一个 while 循环加上上下文工程。文章从产品体验总结规律，用 200 行 Python 代码实现了 Claude Code 的最小版本，证明所有花哨的概念（MCP、Rules、Spec Coding、Skills）本质上都是“如何把正确的上下文喂给 LLM“。</p> </blockquote> 技术要点：</strong></p> Agent 本质</strong> - while 循环 + 上下文工程，LLM 无状态只能通过重放上下文模拟“持续思考“</li> ReAct 模式</strong> - Reasoning（LLM 思考）→ Acting（调用工具）→ Observing（结果反馈）→ 循环直到任务完成</li> 上下文工程核心</strong> - “这一轮让模型看什么“决定能力高低：文件选择、历史压缩、规则表达、工具输出结构化</li> 概念解构</strong> - MCP（标准化上下文提供者）、.cursorrules（系统提示词硬编码补丁）、Spec Coding（挂载 ROM 对抗上下文漂移）、Skills（动态链接库避免撑爆窗口）</li> 200 行实现</strong> - 完整的 Toy Claude Code：工具定义（execute_bash/read_file/write_file/list_files）、工具 Schema、系统提示词、Agent 主循环（Think→Act→Observe）</li> </ul> 应用场景：</strong></p> 帮助开发者理解 Coding Agent 的技术边界，从“如何写代码“转向“如何设计约束、上下文和验证机制“。核心洞察：AI 不会执行代码，只会决定是否调用工具；复杂度从算法/状态机转移到上下文构建。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> Agent Skill 精选集：最值得收藏的 Agent Skills Top 10</a></h3> 来源：</strong> AIGC 胶囊 (AI 探路者) 时间：</strong> 2026-03-05</p> 核心内容：</strong></p> 基于 GitHub 采样调查，整理了最受欢迎和质量最佳的 Agent Skills Top 10 榜单，涵盖技能生成、代码审查、数据分析、PPT 构建、PDF 深度阅读、技术栈专家、数据库管理、研报综述、任务管理、品牌语调等 10 大领域。</p> </blockquote> 技术要点：</strong></p> Skill Creator（技能生成器）</strong> - 元技能，通过引导式对话将 SOP 转化为 SKILL.md 文件</li> Git PR Reviewer（代码审查专家）</strong> - 集成 CI/CD，遵循 Google/Airbnb 规范，具备安全漏洞扫描能力</li> Excel Data Analyst（Excel 分析师）</strong> - 基于 Python Pandas 清洗脏数据、处理缺失值、生成数据透视表</li> Slide Deck Builder（PPT 构建者）</strong> - Markdown/长文自动转换设计精美的 pptx 文件</li> PDF Deep Reader（文档深度解析）</strong> - 分块索引技术处理 100 页 + 长文档，精准提取跨页表格</li> Tech Stack Expert（技术栈专家）</strong> - 封装 Next.js 15+ 等框架最佳实践，防止过时语法</li> Postgres DB Admin（数据库管理员）</strong> - 默认只读保护，支持 Explain 分析和索引优化</li> Research Synthesis（研报综述）</strong> - “搜索 - 筛选 - 验证 - 引用 - 撰写“标准化流程，输出含参考文献的深度报告</li> Linear/Jira Ticket Manager（任务管理）</strong> - 模糊需求拆解为结构化工单，自动补全验收标准</li> Brand Voice Guard（品牌语调守门员）</strong> - 基于企业 Tone of Voice 指南审核并改写文案</li> </ul> 应用场景：</strong></p> Claude Code、Codex、Gemini CLI 等 AI 助手用户，通过安装 Skills 让 AI 直接知道该怎么做，无需每次重复解释需求。适合开发者、数据分析师、产品经理、内容运营等角色提升效率。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 字节跳动超级智能体 DeerFlow 2.0 开源，登顶 GitHub Trending 第一！</a></h3> 来源：</strong> 徐公时间：</strong> 2026-03-02</p> 核心内容：</strong></p> 字节跳动开源 DeerFlow 2.0，短时间 2.2 万 Star 登顶 GitHub Trending 榜首，这是完整的智能体运行环境——让 AI 真正能够“做事“的平台。</p> </blockquote> 技术要点：</strong></p> 技能系统（核心）</strong> - 结构化能力模块（Markdown 文件），按需加载保持精简上下文，支持自定义扩展和复合工作流</li> 子智能体编排</strong> - 复杂任务分解为并行子智能体，每个独立上下文和工具，主导智能体综合输出</li> 沙盒与文件系统</strong> - Docker 容器独立运行，完整文件系统（技能/工作空间/输出），可审计会话零污染</li> 上下文工程</strong> - 激进管理：总结已完成子任务、中间结果卸载到文件系统、压缩非相关内容</li> 长期记忆</strong> - 会话间持久记忆（档案/偏好/知识），本地存储完全控制，越用越了解用户</li> 技术栈</strong> - 基于 LangGraph 和 LangChain，支持本地/Docker/K8s 三种执行模式，MIT 许可证</li> </ul> 应用场景：</strong></p> 深度研究、内容创作、数据管道、工作流自动化，适合需要处理长时复杂任务的团队和个人。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> 上门安装 OpenClaw，年入百万？</a></h3> 来源：</strong> APPSO (虎嗅) 时间：</strong> 2026-03-03</p> 核心内容：</strong></p> OpenClaw 安装服务衍生“上门代装“新业态（海外 3000-6000 美元，国内 500-1000 元），揭示 AI Agent 普及过程中“能学会“与“愿意学“的鸿沟。</p> </blockquote> 技术要点：</strong></p> 安装门槛</strong> - OpenClaw 底层是开发者网关服务，需 Node.js 环境、命令行配置、守护进程、端口开放、Webhook 回调等，对普通用户极不友好</li> 心跳机制成本</strong> - 每 30 分钟唤醒检查邮件/日历/Slack，每次请求包含系统提示词、工具参数、会话历史，开发者实测月消耗 750 美元</li> 安全风险</strong> - 4.2 万 + 暴露实例、九成可绕过认证，ClawHub 恶意插件窃取数据，Google 账号接入触发风控导致封号</li> 典型事故</strong> - Meta AI 负责人 Summer Yue 误授权邮箱访问，OpenClaw 丢失限制指令后批量清空收件箱，强制断电才停止</li> 优化策略</strong> - 按任务路由不同模型、控制 tokens 上限、上下文裁剪、本地模型下沉 (Ollama) 降低 API 依赖</li> </ul> 应用场景：</strong></p> 目标群体：个体创业者/自由职业者（省时间）、有技术认知但不愿折腾的职场白领、跟风购买的普通消费者。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p> AI 漫剧规模化“神器“来了！网宿科技发布边缘 AI 网关：百模即插即用，光同尘、鸥溪网络已率先“减负“</a></h3> 来源：</strong> AIBase News 时间：</strong> 2026-03-05</p> 核心内容：</strong></p> 网宿科技发布“边缘 AI 网关“，将 AI 能力下沉至边缘节点构建“模型中枢“，解决 AI 漫剧规模化生产三大痛点：多模型协同难、延迟与成本高、合规与安全风险。</p> </blockquote> 技术要点：</strong></p> 全球百模“即插即用“</strong> - 支持 DeepSeek、文心一言、OpenAI、Llama 等全球超 100 个主流模型，统一 API 接口实现极速切换与智能调用</li> 智能调度与精细降本</strong> - 内置 AI 缓存与智能路由策略，根据任务复杂程度自动在“高成本旗舰模型“与“高性价比替代模型“间切换，保障成片质量同时实现降本增效</li> 安全“过滤网“</strong> - 集成实时内容审核、权限控制与任务授权功能，在边缘侧完成违规内容拦截，保障生产全链路安全可信</li> 边缘模型托管</strong> - 未来将轻量化模型部署至边缘侧，响应速度提升至毫秒级，满足更高要求的隐私合规需求</li> “边缘算力底座+AI 引擎“双轮驱动</strong> - 推动 AI 漫剧从试验性小规模制作向真正工业化批量生产转型</li> </ul> 应用场景：</strong></p> AI 漫剧工业化生产（脚本→分镜→原画→配音全流程），适合需要多模型协同、成本控制、内容安全的 AI 内容生成企业。</p> </blockquote> 原文链接：</strong> 📌 保存链接</a></p>
Claude Code Agent Teams 完整指南 2026-03-02T00:00:00+00:00 Claude Code Agent Teams 完整指南</h1> 基于 Anthropic 官方文档整理 ⚠️ Agent Teams 目前是实验性功能</strong>，默认关闭，存在已知限制</p> </blockquote> 目录</h2> 什么是 Agent Teams</a></li> 内置工具清单</a></li> 核心架构：谁负责什么</a></li> 共享任务看板</a></li> Agent 间通信机制</a></li> 共享文件 vs 私有-Context</a></li> TeammateTool 的 13 种操作</a></li> Hook 系统</a></li> 文件存储位置</a></li> Token 成本与建议</a></li> 已知限制与处理方式</a></li> 何时选择 Agent Teams vs Subagents</a></li> </ol> 一、什么是 Agent Teams</h2> Agent Teams 让你协调多个 Claude Code 实例</strong>共同完成一项复杂任务。</p> 用户 </span> ↓ </span>Lead Agent（主协调者） </span> ├── Teammate A（独立 Context） </span> ├── Teammate B（独立 Context） </span> └── Teammate C（独立 Context） </span></code></pre> Lead</strong>：创建任务、spawn 成员、监控进度、汇总结果</li> Teammates</strong>：各自独立工作，可互相直接通信，也可与用户直接对话</li> 关键</strong>：每个 Teammate 有自己完全独立的 Context Window，互相不可见</li> </ul> 与 Subagents 的区别</h3> 维度</th> Subagents</th> Agent Teams</th></tr></thead> 运行位置</td> 单个 Session 内部</td> 各自独立的 Session</td></tr> 通信方式</td> 只能向主 Agent 汇报</td> 可互相直接通信</td></tr> Context</td> 共享主 Session</td> 每人独立</td></tr> 适用场景</td> 快速独立子任务</td> 需要协调、相互质疑的复杂任务</td></tr> </tbody></table> 一句话选择标准</strong>：你的 workers 需要互相通信吗？不需要 → Subagents；需要 → Agent Teams。</p> 启用方式</h3> export </span>CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS</span>=</span>1 </span></code></pre> 二、内置工具清单</h2> Claude Code 共有以下内置工具：</p> 文件读取与导航</h3> 工具</th> 功能</th></tr></thead> Read</strong></td> 读取文件内容（优于 cat/head/tail）</td></tr> LS</strong></td> 列出目录（优于 ls 命令）</td></tr> Glob</strong></td> 按模式匹配文件名，结果按修改时间排序</td></tr> Grep</strong></td> 基于 ripgrep 的高性能内容搜索</td></tr> </tbody></table> 文件写入与编辑</h3> 工具</th> 功能</th></tr></thead> Write</strong></td> 创建或覆写文件</td></tr> Edit</strong></td> 对文件指定位置做精确编辑（优于 sed/awk）</td></tr> MultiEdit</strong></td> 单次操作批量编辑文件多处</td></tr> </tbody></table> Notebook 支持</h3> 工具</th> 功能</th></tr></thead> NotebookRead</strong></td> 读取 Jupyter Notebook</td></tr> NotebookEdit</strong></td> 编辑 Notebook 单元格</td></tr> </tbody></table> 命令执行</h3> 工具</th> 功能</th></tr></thead> Bash</strong></td> 在持久 bash 会话中执行 shell 命令</td></tr> </tbody></table> Web 工具</h3> 工具</th> 功能</th></tr></thead> WebFetch</strong></td> 获取指定 URL 的网页内容</td></tr> WebSearch</strong></td> 搜索网络获取最新信息</td></tr> </tbody></table> 任务管理</h3> 工具</th> 功能</th></tr></thead> TodoRead</strong></td> 读取当前会话的任务列表</td></tr> TodoWrite</strong></td> 创建和更新结构化任务列表</td></tr> </tbody></table> Agent 编排</h3> 工具</th> 功能</th></tr></thead> Task</strong>（Agent 工具）</td> 启动专注的子 Agent 完成多步骤任务</td></tr> </tbody></table> 流程控制</h3> 工具</th> 功能</th></tr></thead> ExitPlanMode</strong></td> 退出计划模式，开始执行</td></tr> </tbody></table> 三、核心架构：谁负责什么</h2> Lead Agent 职责</h3> 初始化任务看板（TaskCreate</code>）</li> 设置任务间的依赖关系（TaskUpdate addBlockedBy</code>）</li> Spawn Teammates 并传入初始 prompt</li> 监控整体进度，处理孤儿任务</li> 最终汇总结果</li> </ul> 重要</strong>：Lead 只负责“启动蓝图“，不实时管理每个人。任务流转由 Teammates 自驱动。</p> Teammate 职责</h3> 启动后读取任务看板，认领 available 任务</li> 执行工作，把成果写入共享文件</li> 标记任务完成</li> 发现新需求时可自主创建新任务（动态扩展）</li> 向其他 Agent 发消息通报关键信息</li> </ul> Spawn 是什么</h3> Spawn = 创建并启动一个新的独立进程。每个被 spawn 出来的 Teammate：</p> 是一个全新的 Claude 模型实例</li> 拥有空白的、独立的 Context Window（不继承 Lead 的对话历史）</li> 自动加载项目 CLAUDE.md</code>、MCP Servers、Skills</li> 启动后独立运行，父子之间只通过文件系统和消息通信</li> </ol> 四、共享任务看板</h2> 任务状态流转</h3> pending（有未完成依赖） </span> ↓ 所有依赖 completed → 自动解锁（无需人工干预） </span>available（可认领） </span> ↓ Teammate 认领 </span>in_progress（执行中） </span> ↓ Teammate 标记完成 </span>completed（完成） </span></code></pre> 依赖关系设置</h3> TaskCreate</span>({ id: </span>"1"</span>, subject: </span>"安全审查" </span>}) </span>TaskCreate</span>({ id: </span>"2"</span>, subject: </span>"性能审查" </span>}) </span>TaskCreate</span>({ id: </span>"3"</span>, subject: </span>"汇总报告" </span>}) </span> </span>// #3 依赖 #1 和 #2，两者都完成后 #3 自动解锁 </span>TaskUpdate</span>({ taskId: </span>"3"</span>, addBlockedBy: [</span>"1"</span>, </span>"2"</span>] }) </span></code></pre> 防竞争机制</h3> 任务认领底层使用文件锁（file-lock based claiming）</strong>，防止多个 Teammate 同时认领同一任务。</p> 孤儿任务问题</h3> 如果某个 Teammate 意外退出（Context 耗尽、进程崩溃），它负责的任务会变成“孤儿“（available 但无人认领）。生产级设计</strong>中，Lead Agent 应定期轮询任务看板，发现孤儿任务后：</p> 自己认领并执行</li> 或重新 spawn 新 Teammate 接手</li> 可配合任务超时机制自动重置 in_progress 状态</li> </ul> 五、Agent 间通信机制</h2> 核心原则</h3> Teammate 的文字输出对其他团队成员不可见</strong>。必须通过消息系统主动发送，对方才能收到。</p> </blockquote> 通信方式</h3> 点对点消息</strong>（SendMessage operation: “message”）</p> SendMessage</span>({ </span> operation: </span>"message"</span>, </span> target: </span>"security-reviewer"</span>, </span> content: </span>"支付模块第143行有注入风险，你分析性能时先跳过这个函数" </span>}) </span></code></pre> 广播</strong>（SendMessage operation: “broadcast”）</p> 发给所有 Teammates</li> 代价高：N 个 Teammates = N 条独立消息</li> 推荐优先用点对点</li> </ul> 关闭协商</strong></p> SendMessage</span>({ operation: </span>"shutdown_request"</span>, target: </span>"agent-b"</span>, reason: </span>"任务完成" </span>}) </span>SendMessage</span>({ operation: </span>"rejectShutdown"</span>, request_id: </span>"xxx"</span>, reason: </span>"还有任务未完成" </span>}) </span></code></pre> 通信本质</h3> 通信底层是异步消息传递</strong>（写入文件系统的收件箱）+ 共享任务状态</strong>，不是实时直连。类比：异步工作的远程团队用 Slack + 共享 Jira 看板协作。</p> 六、共享文件 vs 私有 Context</h2> ┌─────────────────────────────────────────────────┐ </span>│ 文件系统（所有人可读写） │ </span>│ 任务看板 ~/.claude/tasks/{team}/tasks.json │ </span>│ 消息收件箱系统管理 │ </span>│ 工作成果 Agent 主动写入的输出文件 │ </span>│ 项目代码所有人通过 Read/Write 工具访问 │ </span>└─────────────────────────────────────────────────┘ </span> </span>┌──────────────┐ ┌──────────────┐ ┌──────────────┐ </span>│ Agent A │ │ Agent B │ │ Agent C │ </span>│ 私有Context │ │ 私有Context │ │ 私有Context │ </span>│ · 分析过程 │ │ · 分析过程 │ │ · 分析过程 │ </span>│ · 中间推理 │ │ · 中间推理 │ │ · 中间推理 │ </span>│ · 临时思路 │ │ · 临时思路 │ │ · 临时思路 │ </span>│ ← 不可见 → │ │ ← 不可见 → │ │ ← 不可见 → │ </span>└──────────────┘ └──────────────┘ └──────────────┘ </span></code></pre> 规则</strong>：需要别人知道的 → 写文件或发消息；自己的思考过程 → 留在 Context，消失就消失。</p> 七、TeammateTool 的 13 种操作</h2> 最新版本将操作拆分到多个工具：</p> Teammate 工具（团队生命周期）</h3> 操作</th> 功能</th></tr></thead> spawnTeam</code></td> 创建新团队，启动 Teammates</td></tr> cleanup</code></td> 关闭所有 Teammate，释放资源</td></tr> </tbody></table> SendMessage 工具（通信）</h3> 操作</th> 功能</th></tr></thead> message</code></td> 点对点发消息给指定 Agent</td></tr> broadcast</code></td> 广播给所有 Agent</td></tr> shutdown_request</code></td> 请求某 Agent 关闭</td></tr> rejectShutdown</code></td> 拒绝关闭请求</td></tr> plan_approval_response</code></td> 批准/拒绝执行计划</td></tr> </tbody></table> Task 工具系列（共享任务板）</h3> 操作</th> 功能</th></tr></thead> TaskCreate</code></td> 创建新任务</td></tr> TaskUpdate</code></td> 更新状态/owner/依赖</td></tr> TaskList</code></td> 列出所有任务（Agent 用此认领工作）</td></tr> TaskGet</code></td> 获取单个任务详情</td></tr> </tbody></table> 其他</h3> 操作</th> 功能</th></tr></thead> discoverTeams</code></td> 发现现有团队</td></tr> requestJoin</code></td> 请求加入团队</td></tr> approveJoin</code></td> 批准加入请求</td></tr> </tbody></table> 八、Hook 系统</h2> Hook 是写在本地的脚本，在 Agent 执行特定动作时自动触发</strong>。</p> 全部 Hook 事件</h3> Hook</th> 触发时机</th> 特点</th></tr></thead> PreToolUse</strong></td> 工具执行之前</td> 唯一能阻止操作的 Hook</strong></td></tr> PostToolUse</strong></td> 工具执行之后</td> 格式化、记录、测试</td></tr> UserPromptSubmit</strong></td> 用户提交消息时</td> 校验、增强输入</td></tr> PermissionRequest</strong></td> Agent 请求权限时</td> 自动批准/拒绝</td></tr> Stop</strong></td> 主 Agent 完成响应时</td> 验证、发通知</td></tr> SubagentStop</strong></td> 子 Agent 完成时</td> 收集子 Agent 结果</td></tr> SessionEnd</strong></td> 会话终止时</td> 清理、归档</td></tr> Setup</strong></td> 项目初始化/维护时</td> 配置环境</td></tr> TeammateIdle</strong></td> Teammate 将进入空闲时</td> exit 2 → 让它继续工作</td></tr> TaskCompleted</strong></td> 任务将被标记完成时</td> exit 2 → 阻止完成，先验证</td></tr> </tbody></table> 三种 Hook 处理器类型</h3> { </span>"type"</span>: </span>"command"</span>, </span>"command"</span>: </span>"npx prettier --write" </span>} </span>{ </span>"type"</span>: </span>"prompt"</span>, </span>"prompt"</span>: </span>"判断这个命令是否影响生产环境: $ARGUMENTS" </span>} </span>{ </span>"type"</span>: </span>"agent"</span>, </span>"prompt"</span>: </span>"检查修改的文件是否有对应测试" </span>} </span></code></pre> 配置示例</h3> // ~/.claude/settings.json </span>{ </span> </span>"hooks"</span>: { </span> </span>"PreToolUse"</span>: [{ </span> </span>"matcher"</span>: </span>"Bash"</span>, </span> </span>"hooks"</span>: [{ </span>"type"</span>: </span>"command"</span>, </span>"command"</span>: </span>"python3 ~/.claude/hooks/safety_check.py" </span>}] </span> }], </span> </span>"PostToolUse"</span>: [{ </span> </span>"matcher"</span>: </span>"Write"</span>, </span> </span>"hooks"</span>: [{ </span>"type"</span>: </span>"command"</span>, </span>"command"</span>: </span>"npx prettier --write $FILE" </span>}] </span> }], </span> </span>"Stop"</span>: [{ </span> </span>"hooks"</span>: [{ </span>"type"</span>: </span>"command"</span>, </span>"command"</span>: </span>"python3 ~/.claude/hooks/verify_done.py" </span>}] </span> }] </span> } </span>} </span></code></pre> Hook 数据流</h3> Agent 准备执行工具 </span> ↓ </span>工具参数通过 stdin 传给 Hook 脚本 </span> ↓ </span>Hook 脚本运行（可读文件、写文件、调 API） </span> ↓ </span>stdout 输出 → Agent 读入自己的 Context </span>exit 0 → 继续执行 </span>exit 1 → 阻止执行（仅 PreToolUse） </span>exit 2 → 发送反馈让 Agent 继续（TeammateIdle/TaskCompleted） </span></code></pre> 九、文件存储位置</h2> 全局目录 ~/.claude/</code></h3> ~/.claude.json # 全局配置（项目映射、MCP设置） </span>~/.claude/ </span>├── settings.json # 全局设置（hooks、权限） </span>├── projects/ # 会话对话记录（JSONL格式） </span>│ └── -Users-你-项目名/ </span>│ └── .jsonl # 每行一条消息，实时写入 </span>├── todos/ # TodoWrite 写入的任务 </span>│ └── {session-id}-.json </span>├── plans/ # Plan Mode 生成的计划 </span>├── skills/ # 全局 Skills </span>├── commands/ # 全局自定义命令 </span>├── teams/ # Agent Teams 配置 </span>│ └── {team-name}/ </span>│ └── config.json # 团队成员、权限 </span>└── tasks/ # Agent Teams 任务看板 </span> └── {team-name}/ </span> ├── tasks.json # 共享任务状态（所有Agent读写） </span> └── .lock # 文件锁（防并发竞争） </span></code></pre> 项目级目录 .claude/</code>（在项目根目录）</h3> 你的项目/ </span>└── .claude/ </span> ├── settings.json # 项目共享设置（可提交 git） </span> ├── settings.local.json # 本机私有设置（gitignore） </span> ├── CLAUDE.md # 项目说明，每次会话自动注入 </span> ├── agents/ # Subagent 定义 </span> ├── commands/ # 自定义 /命令 </span> ├── skills/ # 项目级 Skills </span> └── hooks/ # Hook 脚本 </span></code></pre> 关键设计细节</h3> 会话数据用 JSONL 格式</strong>存储：每条消息是独立的一行，生成后立即写入磁盘。即使程序崩溃，只有最后一条未完成的消息可能丢失，之前全部保留。</p> 十、Token 成本与建议</h2> 每个 Teammate 有独立 Context Window，Token 消耗随 Teammate 数量线性增长</strong></li> 3 个 Teammate ≈ 单 Session 的 3-4 倍 Token 消耗</li> 广播消息消耗 N 倍 Token</li> </ul> 官方建议</strong>：</p> 从 3-5 个 Teammate</strong> 开始</li> 每个 Teammate 分配 5-6 个任务</strong>效率最高</li> 有 15 个独立任务 → 3 个 Teammate 是好的起点</li> 日常任务用单 Session；只在真正需要并行协调时才用 Agent Teams</li> </ul> 十一、已知限制与处理方式</h2> 问题</th> 处理方式</th></tr></thead> Teammate 意外停止</td> 用 Shift+Down 查看输出，直接给它指令，或 spawn 新 Teammate 接手</td></tr> Lead 提前结束</td> 告诉它继续，或让它等 Teammates 完成后再汇总</td></tr> tmux Session 残留</td> tmux ls</code> 查看，tmux kill-session -t <name></code> 清理</td></tr> 会话无法恢复</td> 已知限制，实验性功能阶段暂无完整解决方案</td></tr> </tbody></table> 十二、何时选择 Agent Teams vs Subagents</h2> 推荐使用 Agent Teams</h3> 并行审查</strong>：安全、性能、测试三个角度同时审查同一 PR</li> 竞争假设调试</strong>：多个 Teammate 分别测试不同理论并互相质疑</li> 跨层功能开发</strong>：前端、后端、测试各自独立负责</li> 独立模块开发</strong>：各 Teammate 有独立代码区域，互不覆盖</li> </ul> 不推荐使用 Agent Teams</h3> 顺序依赖性强的任务（A 必须在 B 之前完成，且无并行空间）</li> 需要频繁修改同一个文件</li> 日常简单任务（成本不划算）</li> </ul> 参考：Anthropic 官方文档</a></em></p> Claude Code Agent Teams 详解 2026-03-02T00:00:00+00:00 Claude Code Agent Teams 详解</h1> 基于 Anthropic 官方文档：https://code.claude.com/docs/en/agent-teams</p> ⚠️ Agent Teams 目前是实验性功能</strong>，默认关闭。已知存在会话恢复、任务协调、关闭行为方面的限制。</p> </blockquote> 一、什么是 Agent Teams</h2> Agent Teams 让你协调多个 Claude Code 实例</strong>共同完成一项任务。</p> 一个 Session 担任 Team Lead</strong>，负责协调工作、分配任务、汇总结果</li> 其余 Session 是 Teammates</strong>，各自独立工作，每人有自己的 context window</li> Teammates 之间可以直接互相通信</strong>，不必经过 Lead 中转</li> 用户也可以直接和某个 Teammate 对话</strong>，无需通过 Lead</li> </ul> 与 Subagents 的区别</h3> 维度</th> Subagents</th> Agent Teams</th></tr></thead> 运行位置</td> 单个 Session 内部</td> 各自独立的 Session</td></tr> 汇报方式</td> 只能向主 Agent 汇报</td> 可互相直接通信</td></tr> Context</td> 共享主 Session 的 Context</td> 每人独立 Context Window</td></tr> 适用场景</td> 快速、专注、独立的子任务</td> 需要协调、共享发现、相互质疑的复杂任务</td></tr> </tbody></table> 二、启用方式</h2> # 方式1：环境变量 </span>export </span>CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS</span>=</span>1 </span> </span># 方式2：settings.json </span>{ </span> </span>"env"</span>: </span>{ </span> </span>"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS"</span>: </span>"1" </span> } </span>} </span></code></pre> 启用后，直接用自然语言告诉 Claude 创建团队即可，无需写配置文件：</p> Create an agent team to review PR #142. </span>Spawn three reviewers: </span>- One focused on security implications </span>- One checking performance impact </span>- One validating test coverage </span>Have them each review and report findings. </span></code></pre> 三、核心架构</h2> 3.1 Team Lead 的职责</h3> 根据你的描述创建团队和任务</li> Spawn Teammates 并传入初始 prompt</li> 监控和协调整体进度</li> 收到 Teammate 消息后中转或响应</li> 最终汇总结果</li> </ul> 注意</strong>：Claude 不会在未经你确认的情况下自行创建团队。无论是你要求还是 Claude 建议，都需要你先批准。</p> 3.2 Teammate 的 Context</h3> 每个 Teammate 启动时自动加载：</p> 项目的 CLAUDE.md</code></li> 已配置的 MCP Servers</li> Skills</li> </ul> 不会继承</strong>：Lead 的对话历史。Teammate 从一张“白纸“开始，只拥有 Lead 传给它的 spawn prompt。</p> 3.3 权限继承</h3> Teammates 继承 Lead 的权限设置。可以在 spawn 后为单个 Teammate 修改模式，但不能在 spawn 时指定。建议在 spawn 前在权限设置里预先批准常用操作，以减少中断。</p> 四、共享任务看板（Shared Task List）</h2> 这是 Agent Teams 协调的核心机制之一。</p> 工作原理</h3> 任务看板是一个共享的结构化列表</strong>，所有 Teammates 都能读写。它支持依赖追踪：</p> 任务可以设置依赖（blocked by 其他任务）</li> 当阻塞任务完成后，被阻塞的任务自动解锁</strong>（无需人工干预）</li> Teammates 完成当前任务后，自主认领下一个 available 的任务</li> </ul> 任务状态流转</h3> pending（有依赖未完成） </span> ↓ 依赖全部 completed → 自动解锁 </span>available（可认领） </span> ↓ Teammate 认领 </span>in_progress（执行中） </span> ↓ Teammate 标记完成 </span>completed（完成） </span></code></pre> 谁控制看板</h3> 操作</th> 执行者</th></tr></thead> 初始化任务列表</td> Lead Agent</td></tr> 设置任务依赖关系</td> Lead Agent（初始化时）</td></tr> 认领任务（更新 owner + status）</td> Teammate 自主执行</td></tr> 标记任务完成</td> Teammate 自主执行</td></tr> 发现新需求时创建新任务</td> Teammate 可自主扩展</td></tr> 监控孤儿任务（无人认领）</td> Lead Agent 应定期检查</td></tr> </tbody></table> 关键设计理念</strong>：Lead 只负责启动，任务流转由 Teammates 自驱动。系统通过依赖关系自动解锁，不需要 Lead 实时盯着每个人的进度。</p> 文件锁防竞争</h3> 任务认领底层使用文件锁机制（file-lock based claiming）</strong>，防止多个 Teammate 同时认领同一任务产生竞争条件。</p> 五、Agent 间通信（Mailbox 系统）</h2> 这是 Agent Teams 与 Subagents 的最大区别。</p> 通信方式</h3> 点对点消息（message）</strong>：发给指定 Teammate</p> Teammate 的文字输出对其他成员不可见</li> 必须通过消息系统主动发送，对方才能收到</li> </ul> 广播（broadcast）</strong>：发给所有 Teammates</p> 代价高：发给 N 个 Teammate 需要 N 条独立消息</li> 推荐优先用点对点消息</li> </ul> 消息自动送达</strong>：Teammate 消息自动到达 Lead，无需 Lead 主动轮询。</p> 什么时候必须发消息</h3> 以下情况需要显式发消息，否则其他 Agent 不会知道：</p> 某个 Teammate 完成了会影响其他人工作的发现</li> 需要通知某人跳过/注意某个模块</li> 请求另一个 Teammate 的状态更新</li> </ul> 团队和消息存储位置</h3> 官方文档说明：团队和任务存储在本地</strong>（本地文件系统），具体路径由系统管理。</p> 六、共享文件 vs 私有 Context</h2> 什么存在共享文件系统（所有人可见）</h3> 任务看板（状态、依赖、owner）</li> Teammate 之间的消息（通过消息系统写入）</li> 工作成果（Teammate 主动写入的输出文件，如 findings.md）</li> 项目代码文件（所有人通过 Read/Write 工具访问）</li> </ul> 什么存在 Teammate 自己的 Context（只有自己可见）</h3> 分析过程和中间推理</li> 读了哪些文件的历史</li> 临时思路和草稿</li> 对话历史</li> </ul> 规则</strong>：需要别人知道的信息 → 写文件或发消息；自己的思考过程 → 留在 Context，会话结束后消失。</p> 七、并发运行方式（Display Modes）</h2> Agent Teams 支持三种后端运行方式，系统自动检测最佳方式：</p> 模式</th> 特点</th> 适用场景</th></tr></thead> tmux</strong>（分屏）</td> 每个 Teammate 显示在独立的终端窗口分栏</td> 需要可视化监控</td></tr> iTerm2</strong>（分屏）</td> 在 iTerm2 内显示分栏</td> Mac 用户</td></tr> in-process</strong>（后台）</td> 不显示独立窗口，最快</td> 纯自动化，不需要看进度</td></tr> </tbody></table> # 手动指定运行模式 </span>export </span>CLAUDE_CODE_SPAWN_BACKEND</span>=</span>tmux </span># 显示分屏 </span>export </span>CLAUDE_CODE_SPAWN_BACKEND</span>=</span>in-process </span># 后台运行（最快） </span></code></pre> 在 in-process 模式下，按 Shift+Down</strong> 可以切换查看各个 Teammate 的输出。</p> 八、Agent Teams 专用 Hooks</h2> 除了常规 Hooks，Agent Teams 有两个专用事件：</p> TeammateIdle</h3> 当某个 Teammate 即将进入空闲状态时触发。</p> 以 exit code 2</strong> 退出 → 向 Teammate 发送反馈，让它继续工作</li> 用途：防止 Teammate 提前退出，确保任务继续</li> </ul> TaskCompleted</h3> 当某个任务即将被标记为完成时触发。</p> 以 exit code 2</strong> 退出 → 阻止任务完成，发送反馈</li> 用途：在任务关闭前做验证（如运行测试、检查输出质量）</li> </ul> 九、Token 成本</h2> 每个 Teammate 有独立的 Context Window</strong>，Token 消耗随活跃 Teammate 数量线性增长</strong></li> 3 个 Teammate 的团队消耗约为单 Session 的 3-4 倍</strong></li> 广播消息会消耗 N 倍 Token（发给 N 个 Teammate）</li> </ul> 官方建议</h3> 从 3-5 个 Teammate</strong> 开始，这是效率和协调成本的最佳平衡点</li> 每个 Teammate 分配 5-6 个任务</strong>效率最高</li> 如果有 15 个独立任务，3 个 Teammate 是好的起点</li> 常规任务用单 Session 更划算；只在真正需要并行协调时才用 Agent Teams</li> </ul> 十、已知限制（官方说明）</h2> Agent Teams 目前是实验性功能，存在以下已知问题：</p> 会话恢复</strong>：无法可靠地恢复中断的 Agent Teams 会话</li> 任务协调</strong>：在复杂依赖场景下可能出现任务协调问题</li> 关闭行为</strong>：Lead 可能在所有任务实际完成前就决定团队结束</li> </ul> 遇到问题的处理方式</h3> Teammate 因错误停止</strong>：用 Shift+Down 查看其输出，直接给它额外指令，或 spawn 新 Teammate 继续工作。</p> Lead 提前结束</strong>：告诉它继续，或告诉它等 Teammate 完成后再进行汇总。</p> tmux Session 残留</strong>：</p> tmux</span> ls </span>tmux</span> kill-session</span> -t </span><</span>session-name</span>> </span></code></pre> 十一、最佳适用场景</h2> 推荐使用 Agent Teams</h3> 并行研究/审查</strong>：多个角度同时调查同一问题（如 PR 审查：安全、性能、测试各一人）</li> 竞争假设调试</strong>：多个 Teammate 分别测试不同理论并相互质疑，避免单一 Agent 的“确认偏误“</li> 跨层功能开发</strong>：前端、后端、测试各由不同 Teammate 负责，互不干扰</li> 独立模块开发</strong>：各 Teammate 拥有独立的代码区域，不会互相覆盖</li> </ul> 不推荐使用 Agent Teams（用单 Session 或 Subagents 更好）</h3> 顺序依赖性强的任务（A 必须在 B 之前完成）</li> 需要频繁修改同一个文件</li> 依赖关系复杂的工作</li> 日常简单任务（成本不划算）</li> </ul> 十二、与 Subagents 的选择原则</h2> 一句话判断标准</strong>（来自官方文档）：</p> 你的 workers 需要互相通信吗？</p> 不需要</strong> → 用 Subagents</li> 需要</strong> → 用 Agent Teams</li> </ul> </blockquote> 如果你在用并行 Subagents 但遇到了 Context 限制，或者 Subagents 之间需要共享信息，Agent Teams 是自然的升级路径。</p> 参考文档：https://code.claude.com/docs/en/agent-teams</em> 最后更新：2026年3月</em></p> Python的禅 2025-10-14T00:00:00+00:00 翻译自https://peps.python.org/pep-0020</a></p> 优美胜于丑陋 Beautiful is better than ugly.</li> 明了胜于晦涩（Explicit is better than implicit.）</li> 简洁胜于复杂（Simple is better than complex.）</li> 复杂胜于凌乱（Complex is better than complicated.）</li> 扁平胜于嵌套（Flat is better than nested.）</li> 稀疏胜于密集（Sparse is better than dense.）</li> 可读性至关重要（Readability counts.）</li> 特殊情况不足以打破规则（Special cases aren’t special enough to break the rules.）</li> 尽管实用性高于纯粹性（Although practicality beats purity.）</li> 错误绝不能悄悄忽略（Errors should never pass silently.）</li> 除非明确声明要忽略（Unless explicitly silenced.）</li> 面对歧义，拒绝猜测的诱惑（In the face of ambiguity, refuse the temptation to guess.）</li> 做一件事应该有且最好只有一种显而易见的方式（There should be one– and preferably only one –obvious way to do it.）</li> 尽管这种方式最初可能并不明显，除非你是荷兰人（Although that way may not be obvious at first unless you’re Dutch.）（注：此处 “荷兰人” 暗指 Python 创始人吉多・范罗苏姆（Guido van Rossum），他是荷兰人，强调其设计理念的权威性）</li> 现在做胜于永远不做（Now is better than never.）</li> 尽管 “永远不做” 往往胜于 “现在就做（却做错）”（Although never is often better than right</em> now.）（注：right</em> now 加星号强调 “当下仓促行动”，暗指避免未经思考的草率开发）</li> 若实现方案难以解释，那它一定是个坏主意（If the implementation is hard to explain, it’s a bad idea.）</li> 若实现方案易于解释，它或许是个好主意（If the implementation is easy to explain, it may be a good idea.）</li> 命名空间是个绝妙的主意 —— 让我们多利用它吧！（Namespaces are one honking great idea – let’s do more of those!）（注：“honking great” 为口语化表达，意为 “非常棒、极其出色”，体现对命名空间设计的认可）</li> </ol> 光猫不改桥接的ipv6网络配置 2025-06-18T00:00:00+00:00 </p> graph LR </span>光猫 --> ASUS </span>ASUS --> R2S </span>ASUS --> NAS </span>R2S --> 小米 </span>小米 --> PC </span></code></pre> 光猫：未改桥接，关ipv6防火墙，DMZ到ASUS ASUS：做主路由，开ipv6防火墙，ipv6选passthrough模式 R2S：关ipv6防火墙，所有接口ipv6都选中继模式小米：改成中继模式当成R2S的AP使用</p> 软件工程中的博弈论 2025-04-21T00:00:00+00:00 翻译自: https://medium.com/@myroslavazel/game-theory-in-software-engineering-812101b77840</a></p> </p> 正如各种敏捷专家所建议的那样，博弈论</a>与敏捷团队的工作方式有着紧密的联系。</p> 根据他们的说法，关键在于最大化团队目标而不是个人奖励。在博弈论中，决策者从大量策略中选择一个行动。创建一个目标函数，反映此人的利益，并依赖于所选择的策略。</p> 冲突情况在于决策并非由一个人做出，而是一群人做出，结果不仅取决于他选择的策略，还取决于其他玩家的决策。从数学模型的角度来看，这种冲突被称为游戏，冲突的参与者被称为玩家。博弈论的主要前提是：系统中的任何参与者都被自动认为是理性的（与操作方在同一水平线上）并尽力实现其目标。</p> 不幸的是，博弈论是精确数学中较少为人知的领域之一，与人文科学交织在一起，侧重于个人的心理方面。然而，当你是一部分游戏并决定下一步时，你需要考虑其他人的选择。记住，当你考虑他们的选择时，他们也正在以同样的方式思考。在提出反映其他“玩家”想法的自己策略时，你需要知道他们也在这样做。</p> 博弈论最好体现了项目管理（PM）和商业分析（BA）的思维方式，虽然它可以应用于软件工程的任何领域。</p> 博弈论作为项目管理工具</h2> 博弈论最初是为了预测一名玩家在另一名玩家的损失下会表现得更好而开发的。如今，博弈论已经扩展到处理广泛的情形和互动，包括人类玩家和非人类玩家（例如计算机）。因此，博弈论是项目管理的优秀工具。在这里，博弈论是一种数学方法，用于分析计算出的情形，其中一个人的成功基于其他人的选择。更正式地，它是智能理性决策者之间冲突和合作的数学模型的研究。为了确定玩家的可能动作，有必要进行一定的工作，可以分为几个部分。</p> 在任何谈判过程中，项目经理需要考虑以下几点：</p> 你试图解决的问题是什么？你最终想解决哪些问题？进入新市场，扩大生产——最终目标的制定始终重要。如何将你的目标与市场中已知的战略决策相关联？</p> </li> 谁是玩家？一个常见的错误是认为你只是在与竞争对手“战斗”，胜者只能有一个。在任何博弈模型中，玩家可能比你想象的要多得多。博弈的结果可能是一个总体上的胜利。</p> </li> 哪些玩家会对你的决策成功产生影响？</p> </li> </ol> 为了在项目管理中使用博弈论，请根据以上问题列出玩家名单。然后为每个玩家回答以下问题：</p> 是否存在时间问题？谁在赶时间，谁可以拖延？玩家是独立决策还是等待其他玩家决策？</p> </li> 哪些玩家可以承诺帮助你和项目？优先考虑这些玩家。</p> </li> 你有谈判的角度吗？如果玩家有不同的偏好、优先级或能力，互利是可能的。如果互利是可能的，则可以进行谈判。</p> </li> 玩家有什么目标？把自己放在每个玩家的立场上，假设他们的目标和行动从他们的角度来看是理性的，尽管你可能不同意。博弈论中，通常认为每个玩家的最终目标是最大化利润。但在实践中情况并非总是如此。有时玩家会设定其他目标，例如占领市场的某个细分市场或提高品牌的知名度作为一个操作方，你需要正确确定所有其他参与者的目标。</p> </li> </ul> 以上述方式使用博弈论可以帮助你理解人们的行为和互动——这是成功管理项目和避免教育项目中的沟通风险所必需的基本技能。</p> 在我们准备和接近谈判情况时，考虑以下问题：</p> 此人有何获利或亏损？他们是否有时间限制？</p> </li> 如果合作，提前共享细节是否符合我们的最佳利益，并确定我们会同时或顺序进行谈判，是否对双方有利？</p> </li> 对于合作有哪些共同的和可实现的目标，而对于不合作，我们正在谈判的对象的目标是什么？</p> </li> 此人能否代表自己或他人做出承诺？</p> </li> 评估他人的策略，我们的策略或方法有哪些潜在的风险领域？他们可以如何利用他们对我们的了解来获得优势？</p> </li> </ul> Alistair Cockburn最初将软件开发比作博弈论中的发明和沟通的合作游戏。根据他的说法，每个项目都是一个游戏，它适应于更大的企业战略游戏。</p> 道德经 2025-03-20T00:00:00+00:00 【第一章】道可道，非常道；名可名，非常名。无名天地之始，有名万物之母。故常无欲，以观其妙；常有欲，以观其徼（jiào）。此两者同出而异名，同谓之玄，玄之又玄，众妙之门。</p> 【第二章】天下皆知美之为美，斯恶（è）已；皆知善之为善，斯不善已。故有无相生，难易相成，长短相较，高下相倾，音声相和（hè），前后相随。是以圣人处无为之事，行不言之教，万物作焉而不辞，生而不有，为而不恃，功成而弗居。夫（fú）唯弗居，是以不去。</p> 【第三章】不尚贤，使民不争；不贵难得之货，使民不为盗；不见（xiàn）可欲，使民心不乱。是以圣人之治，虚其心，实其腹；弱其志，强其骨。常使民无知无欲，使夫（fú）智者不敢为也。为无为，则无不治。</p> 【第四章】道冲而用之或不盈，渊兮似万物之宗。挫其锐，解其纷，和其光，同其尘。湛兮似或存，吾不知谁之子，象帝之先。</p> 【第五章】天地不仁，以万物为刍（chú）狗；圣人不仁，以百姓为刍狗。天地之间，其犹橐龠（tuóyuè）乎？虚而不屈，动而愈出。多言数（shuò）穷，不如守中。</p> 【第六章】谷神不死，是谓玄牝（pìn），玄牝之门，是谓天地根。绵绵若存，用之不勤。</p> 【第七章】天长地久。天地所以能长且久者，以其不自生，故能长生。是以圣人后其身而身先，外其身而身存。非以其无私邪（yé）？故能成其私。</p> 【第八章】上善若水。水善利万物而不争，处众人之所恶（wù），故几（jī）于道。居善地，心善渊，与善仁，言善信，正善治，事善能，动善时。夫唯不争，故无尤。</p> 【第九章】持而盈之，不如其已。揣(chuǎi)而锐之，不可长保。金玉满堂，莫之能守。富贵而骄，自遗（yí）其咎。功成身退，天之道。</p> 【第十章】载（zài）营魄抱一，能无离乎？专气致柔，能婴儿乎？涤除玄览，能无疵乎？爱民治国，能无知（zhì）乎？天门开阖（hé），能无雌乎？明白四达，能无为乎？生之、畜（xù）之，生而不有，为而不恃，长（zhǎng）而不宰，是谓玄德。</p> 【第十一章】三十辐共一毂（gǔ），当其无，有车之用。埏埴（shān zhí）以为器，当其无，有器之用。凿户牖（yǒu）以为室，当其无，有室之用。故有之以为利，无之以为用。</p> 【第十二章】五色令人目盲，五音令人耳聋，五味令人口爽，驰骋畋（tián）猎令人心发狂，难得之货令人行妨。是以圣人为腹不为目，故去彼取此。</p> 【第十三章】宠辱若惊，贵大患若身。何谓宠辱若惊？宠为下，得之若惊，失之若惊，是谓宠辱若惊。何谓贵大患若身？吾所以有大患者，为吾有身，及吾无身，吾有何患！故贵以身为天下，若可寄天下；爱以身为天下，若可托天下。</p> 【第十四章】视之不见名曰夷，听之不闻名曰希，搏之不得名曰微。此三者不可致诘（jié），故混（hùn）而为一。其上不皦（jiǎo皎），其下不昧。绳绳(mǐn mǐn )不可名，复归于无物，是谓无状之状，无物之象。是谓惚恍。迎之不见其首，随之不见其后。执古之道，以御今之有，能知古始，是谓道纪。</p> 【第十五章】古之善为士者，微妙玄通，深不可识。夫唯不可识，故强(qiǎng)为之容。豫焉若冬涉川，犹兮若畏四邻，俨兮其若容，涣兮若冰之将释，敦兮其若朴，旷兮其若谷，混兮其若浊。孰能浊以静之徐清？孰能安以久动之徐生？保此道者不欲盈，夫唯不盈，故能蔽不新成。</p> 【第十六章】致虚极，守静笃（dǔ），万物并作，吾以观复。夫物芸芸，各复归其根。归根曰静，是谓复命。复命曰常，知常曰明，不知常，妄作，凶。知常容，容乃公，公乃王（wàng），王（wàng）乃天，天乃道，道乃久，没（mò）身不殆。</p> 【第十七章】太上，下知有之。其次，亲而誉之。其次，畏之。其次，侮之。信不足焉，有不信焉。悠兮其贵言。功成事遂，百姓皆谓我自然。</p> 【第十八章】大道废，有仁义；慧智出，有大伪；六亲不和，有孝慈；国家昏乱，有忠臣。</p> 【第十九章】绝圣弃智，民利百倍；绝仁弃义，民复孝慈；绝巧弃利，盗贼无有。此三者，以为文不足，故令有所属，见（xiàn）素抱朴，少私寡欲。</p> 【第二十章】绝学无忧。唯之与阿（ē），相去几何？善之与恶，相去若何？人之所畏，不可不畏。荒兮其未央哉！众人熙熙，如享太牢，如春登台。我独泊兮其未兆，如婴儿之未孩。傫傫（lěi）兮若无所归。众人皆有余，而我独若遗。我愚人之心也哉！沌沌兮！俗人昭昭，我独昏昏；俗人察察，我独闷闷。澹（dàn）兮其若海，飂（liù）兮若无止。众人皆有以，而我独顽似鄙。我独异于人，而贵食(sì)母。</p> 【第二十一章】孔德之容，惟道是从。道之为物，惟恍惟惚。惚兮恍兮，其中有象；恍兮惚兮，其中有物。窈（yǎo）兮冥兮，其中有精；其精甚真，其中有信。自古及今，其名不去，以阅众甫。吾何以知众甫之状哉？以此。</p> 【第二十二章】曲则全，枉则直，洼则盈，敝则新，少则得，多则惑。是以圣人抱一，为天下式。不自见（xiàn）故明，不自是故彰，不自伐故有功，不自矜故长。夫唯不争，故天下莫能与之争。古之所谓曲则全者，岂虚言哉！诚全而归之。</p> 【第二十三章】希言自然。故飘风不终朝（zhāo），骤雨不终日。孰为此者？天地。天地尚不能久，而况于人乎？故从事于道者，道者同于道，德者同于德，失者同于失。同于道者，道亦乐得之；同于德者，德亦乐得之；同于失者，失亦乐得之。信不足焉，有不信焉。</p> 【第二十四章】企者不立，跨者不行，自见（xiàn）者不明，自是者不彰，自伐者无功，自矜者不长。其在道也，曰余食赘（zhuì）行。物或恶（wù）之，故有道者不处（chǔ）。</p> 【第二十五章】有物混（hùn）成，先天地生。寂兮寥兮，独立不改，周行而不殆，可以为天下母。吾不知其名，字之曰道，强(qiǎng)为之名曰大。大曰逝，逝曰远，远曰反。故道大，天大，地大，王亦大。域中有四大，而王居其一焉。人法地，地法天，天法道，道法自然。</p> 【第二十六章】重为轻根，静为躁君。是以圣人终日行不离辎（zī）重。虽有荣观（guàn），燕处超然，奈何万乘（shèng）之主，而以身轻天下？轻则失本，躁则失君。</p> 【第二十七章】善行无辙迹，善言无瑕谪(xiá zhé)，善数（shǔ）不用筹策，善闭无关楗（jiàn）而不可开，善结无绳约而不可解。是以圣人常善救人，故无弃人；常善救物，故无弃物，是谓袭明。故善人者，不善人之师；不善人者，善人之资。不贵其师，不爱其资，虽智大迷，是谓要妙。</p> 【第二十八章】知其雄，守其雌，为天下溪。为天下溪，常德不离，复归于婴儿。知其白，守其黑，为天下式。为天下式，常德不忒（tè），复归于无极。知其荣，守其辱，为天下谷。为天下谷，常德乃足，复归于朴。朴散则为器，圣人用之则为官长（zhǎng）。故大制不割。</p> 【第二十九章】将欲取天下而为之，吾见其不得已。天下神器，不可为也。为者败之，执者失之。故物或行或随，或歔（xū）或吹，或强或羸（léi），或挫或隳（huī）。是以圣人去甚，去奢，去泰。</p> 【第三十章】以道佐人主者，不以兵强天下，其事好（hào）还。师之所处，荆棘生焉。大军之后，必有凶年。善有果而已，不敢以取强。果而勿矜，果而勿伐，果而勿骄，果而不得已，果而勿强。物壮则老，是谓不道，不道早已。</p> 【第三十一章】夫佳兵者，不祥之器。物或恶（wù）之，故有道者不处（chǔ）。君子居则贵左，用兵则贵右。兵者，不祥之器，非君子之器。不得已而用之，恬淡为上，胜而不美。而美之者，是乐(yào)杀人。夫乐(yào)杀人者，则不可以得志于天下矣。吉事尚左，凶事尚右。偏将军居左，上将军居右，言以丧（sāng）礼处之。杀人之众，以哀悲泣之，战胜，以丧礼处之。</p> 【第三十二章】道常无名，朴虽小，天下莫能臣也。侯王若能守之，万物将自宾。天地相合以降甘露，民莫之令而自均。始制有名，名亦既有，夫亦将知止。知止可以不殆。譬道之在天下，犹川谷之于江海。</p> 【第三十三章】知人者智，自知者明。胜人者有力，自胜者强。知足者富，强行者有志，不失其所者久，死而不亡者寿。</p> 【第三十四章】大道泛兮，其可左右。万物恃之而生而不辞，功成不名有，衣养万物而不为主，常无欲，可名于小；万物归焉而不为主，可名为大。以其终不自为大，故能成其大。</p> 【第三十五章】执大象，天下往；往而不害，安平太。乐（yuè）与饵，过客止。道之出口，淡乎其无味，视之不足见（jiàn），听之不足闻，用之不足既。</p> 【第三十六章】将欲歙（xī）之，必固张之；将欲弱之，必固强之；将欲废之，必固兴之；将欲夺之，必固与之，是谓微明。柔弱胜刚强。鱼不可脱于渊，国之利器不可以示人。</p> 【第三十七章】道常无为而无不为，侯王若能守之，万物将自化。化而欲作，吾将镇之以无名之朴。无名之朴，夫亦将无欲。不欲以静，天下将自定。</p> 【第三十八章】上德不德，是以有德；下德不失德，是以无德。上德无为而无以为，下德为之而有以为。上仁为之而无以为，上义为之而有以为，上礼为之而莫之应，则攘(rǎng)臂而扔之。故失道而后德，失德而后仁，失仁而后义，失义而后礼。夫礼者，忠信之薄(bó)而乱之首。前识者，道之华而愚之始。是以大丈夫处其厚，不居其薄(bó)；处其实，不居其华。故去彼取此。</p> 【第三十九章】昔之得一者，天得一以清，地得一以宁，神得一以灵，谷得一以盈，万物得一以生，侯王得一以为天下贞。其致之。天无以清将恐裂，地无以宁将恐发（fèi，“发”通“废”），神无以灵将恐歇，谷无以盈将恐竭，万物无以生将恐灭，侯王无以贵高将恐蹶（jué）。故贵以贱为本，高以下为基。是以侯王自谓孤寡不穀（谷gǔ）。此非以贱为本邪（yé）？非乎？故致数（shuò）舆（yù）无舆。不欲琭（lù）琭如玉，珞（luò）珞如石。</p> 【第四十章】反者，道之动；弱者，道之用。天下万物生于有，有生于无。</p> 【第四十一章】上士闻道，勤而行之；中士闻道，若存若亡；下士闻道，大笑之，不笑不足以为道。故建言有之：明道若昧，进道若退，夷道若颣（lèi）。上德若谷，大白若辱，广德若不足，建德若偷，质真若渝（yú）。大方无隅（yú），大器晚成，大音希声，大象无形。道隐无名，夫唯道善贷且成。</p> 【第四十二章】道生一，一生二，二生三，三生万物。万物负阴而抱阳，冲气以为和。人之所恶（wù），唯孤寡不穀（谷gǔ），而王公以为称（chēng）。故物，或损之而益，或益之而损。人之所教（jiào），我亦教之。强梁者不得其死，吾将以为教父。</p> 【第四十三章】天下之至柔，驰骋天下之至坚，无有入无间，吾是以知无为之有益。不言之教，无为之益，天下希及之。</p> 【第四十四章】名与身孰亲？身与货孰多？得与亡孰病？是故甚爱必大费，多藏必厚亡。知足不辱，知止不殆，可以长久。</p> 【第四十五章】大成若缺，其用不弊。大盈若冲，其用不穷。大直若屈，大巧若拙，大辩若讷。躁胜寒，静胜热。清静为天下正。</p> 【第四十六章】天下有道，却走马以粪；天下无道，戎马生于郊。祸莫大于不知足，咎莫大于欲得，故知足之足，常足矣。</p> 【第四十七章】不出户，知天下；不窥牖，见天道。其出弥远，其知弥少。是以圣人不行而知，不见而名，不为而成。</p> 【第四十八章】为学日益，为道日损。损之又损，以至于无为，无为而无不为。取天下常以无事，及其有事，不足以取天下。</p> 【第四十九章】圣人无常心，以百姓心为心。善者，吾善之；不善者，吾亦善之，德善。信者，吾信之；不信者，吾亦信之，德信。圣人在天下歙歙（xīxī），为天下浑其心。（百姓皆注其耳目），圣人皆孩之。</p> 【第五十章】出生入死。生之徒十有三，死之徒十有三。人之生动之死地，亦十有三。夫何故？以其生生之厚。盖闻善摄生者，陆行不遇兕（sì）虎，入军不被（pī）甲兵，兕无所投其角，虎无所措其爪（zhǎo），兵无所容其刃。夫何故？以其无死地。</p> 【第五十一章】道生之，德畜（xù）之，物形之，势成之。是以万物莫不尊道而贵德。道之尊，德之贵，夫莫之命而常自然。故道生之，德畜之。长之、育之、亭之、毒之、养之、覆之。生而不有，为而不恃，长（zhǎng）而不宰，是谓玄德。</p> 【第五十二章】天下有始，以为天下母。既得其母，以知其子；既知其子，复守其母，没（mò）身不殆。塞（sè）其兑，闭其门，终身不勤。开其兑，济其事，终身不救。见（jiàn）小曰明，守柔曰强。用其光，复归其明，无遗身殃，是为习常。</p> 【第五十三章】使我介然有知，行于大道，唯施（迤yí）是畏。大道甚夷，而民好径。朝（cháo）甚除，田甚芜，仓甚虚。服文彩，带利剑，厌饮食，财货有余，是为盗夸。非道也哉！</p> 【第五十四章】善建者不拔，善抱者不脱，子孙以祭祀不辍。修之于身，其德乃真；修之于家，其德乃余；修之于乡，其德乃长（zhǎng）；修之于国，其德乃丰；修之于天下，其德乃普。故以身观身，以家观家，以乡观乡，以国观国，以天下观天下。吾何以知天下然哉？以此。</p> 【第五十五章】含德之厚，比于赤子。蜂虿（chài）虺（huǐ）蛇不螫(shì)，猛兽不据，攫(jué)鸟不搏。骨弱筋柔而握固。未知牝牡之合而全作，精之至也。终日号而不嗄（shà），和之至也。知和曰常，知常曰明，益生曰祥，心使气曰强。物壮则老，谓之不道，不道早已。</p> 【第五十六章】知（zhì）者不言，言者不知（zhì）。塞（sè）其兑，闭其门，挫其锐；解其纷，和其光，同其尘，是谓玄同。故不可得而亲，不可得而疏；不可得而利，不可得而害；不可得而贵，不可得而贱，故为天下贵。</p> 【第五十七章】以正治国，以奇用兵，以无事取天下。吾何以知其然哉？以此。天下多忌讳，而民弥贫；民多利器，国家滋昏；人多伎（jì）巧，奇物滋起；法令滋彰，盗贼多有。故圣人云：“我无为而民自化，我好静而民自正，我无事而民自富，我无欲而民自朴。”</p> 【第五十八章】其政闷闷，其民淳淳；其政察察，其民缺缺。祸兮福之所倚，福兮祸之所伏。孰知其极？其无正。正复为奇，善复为妖，人之迷，其日固久。是以圣人方而不割，廉而不刿（guì），直而不肆，光而不耀。</p> 【第五十九章】治人事天莫若啬（sè）。夫唯啬，是谓早服。早服谓之重(chóng)积德，重(chóng)积德则无不克，无不克则莫知其极，莫知其极，可以有国。有国之母，可以长久。是谓深根固柢（dǐ），长生久视之道。</p> 【第六十章】治大国若烹小鲜。以道莅（lì）天下，其鬼不神。非其鬼不神，其神不伤人；非其神不伤人，圣人亦不伤人。夫两不相伤，故德交归焉。</p> 【第六十一章】大国者下流。天下之交，天下之牝。牝常以静胜牡，以静为下。故大国以下小国，则取小国；小国以下大国，则取大国。故或下以取，或下而取。大国不过欲兼畜（xù）人，小国不过欲入事人，夫两者各得其所欲，大者宜为下。</p> 【第六十二章】道者万物之奥，善人之宝，不善人之所保。美言可以市，尊行可以加人。人之不善，何弃之有！故立天子，置三公，虽有拱璧以先驷马，不如坐进此道。古之所以贵此道者何？不曰以求得，有罪以免邪（yé）？故为天下贵。</p> 【第六十三章】为无为，事无事，味无味。大小多少，报怨以德。图难于其易，为大于其细。天下难事必作于易，天下大事必作于细，是以圣人终不为大，故能成其大。夫轻诺必寡信，多易必多难，是以圣人犹难之。故终无难矣。</p> 【第六十四章】其安易持，其未兆易谋，其脆易泮（pàn），其微易散。为之于未有，治之于未乱。合抱之木，生于毫末；九层之台，起于累土；千里之行，始于足下。为者败之，执者失之。是以圣人无为，故无败；无执，故无失。民之从事，常于几成而败之。慎终如始，则无败事。是以圣人欲不欲，不贵难得之货。学不学，复众人之所过。以辅万物之自然，而不敢为。</p> 【第六十五章】古之善为道者，非以明民，将以愚之。民之难治，以其智多。故以智治国，国之贼；不以智治国，国之福。知此两者，亦稽（jī）式。常知稽式，是谓玄德。玄德深矣，远矣，与物反矣，然后乃至大顺。</p> 【第六十六章】江海所以能为百谷王者，以其善下之，故能为百谷王。是以欲上民，必以言下之；欲先民，必以身后之。是以圣人处上而民不重，处前而民不害，是以天下乐推而不厌。以其不争，故天下莫能与之争。</p> 【第六十七章】天下皆谓我道大，似不肖（xiào）。夫唯大，故似不肖。若肖，久矣其细也夫。我有三宝，持而保之。一曰慈，二曰俭，三曰不敢为天下先。慈，故能勇；俭，故能广；不敢为天下先，故能成器长（zhǎng）。今舍慈且勇，舍俭且广，舍后且先，死矣！夫慈，以战则胜，以守则固，天将救之，以慈卫之。</p> 【第六十八章】善为士者不武，善战者不怒，善胜敌者不与，善用人者为之下。是谓不争之德，是谓用人之力，是谓配天古之极。</p> 【第六十九章】用兵有言，吾不敢为主而为客，不敢进寸而退尺。是谓行（xíng）无行（háng），攘(rǎng)无臂，扔无敌，执无兵。祸莫大于轻敌，轻敌几丧吾宝。故抗兵相加，哀者胜矣。</p> 【第七十章】吾言甚易知，甚易行，天下莫能知，莫能行。言有宗，事有君。夫唯无知，是以不我知。知我者希，则我者贵，是以圣人被（pī，“被”同“披”）褐怀玉。</p> 【第七十一章】知不知，上；不知知，病。夫唯病病，是以不病。圣人不病，以其病病，是以不病。</p> 【第七十二章】民不畏威，则大威至。无狎（xiá）其所居，无厌（yà，“厌”同“压”）其所生。夫唯不厌（yà，“厌”同“压”），是以不厌(yàn)。是以圣人自知，不自见（xiàn）；自爱，不自贵。故去彼取此。</p> 【第七十三章】勇于敢则杀，勇于不敢则活。此两者，或利或害。天之所恶（wù），孰知其故？是以圣人犹难之。天之道，不争而善胜，不言而善应，不召而自来，繟（chǎn）然而善谋。天网恢恢，疏而不失。</p> 【第七十四章】民不畏死，奈何以死惧之！若使民常畏死，而为奇者，吾得执而杀之，孰敢？常有司杀者杀，夫代司杀者杀，是谓代大匠斫（zhuó）。夫代大匠斫者，希有不伤其手矣。</p> 【第七十五章】民之饥，以其上食税之多，是以饥。民之难治，以其上之有为，是以难治。民之轻死，以其求生之厚，是以轻死。夫唯无以生为者，是贤于贵生。</p> 【第七十六章】人之生也柔弱，其死也坚强。万物草木之生也柔脆，其死也枯槁。故坚强者死之徒，柔弱者生之徒。是以兵强则不胜，木强则兵。强大处下，柔弱处上。</p> 【第七十七章】天之道，其犹张弓与！高者抑之，下者举之；有余者损之，不足者补之。天之道，损有余而补不足。人之道则不然，损不足以奉有余。孰能有余以奉天下？唯有道者。是以圣人为而不恃，功成而不处，其不欲见（xiàn）贤。</p> 【第七十八章】天下莫柔弱于水，而攻坚强者莫之能胜，其无以易之。弱之胜强，柔之胜刚，天下莫不知，莫能行。是以圣人云，受国之垢，是谓社稷主；受国不祥，是为天下王。正言若反。</p> 【第七十九章】和大怨，必有余怨，安可以为善？是以圣人执左契，而不责于人。有德司契，无德司彻。天道无亲，常与善人。</p> 【第八十章】小国寡民，使有什伯（bǎi）之器而不用，使民重（zhòng）死而不远徙(xí)。虽有舟舆，无所乘之；虽有甲兵，无所陈之；使人复结绳而用之。甘其食，美其服，安其居，乐其俗。邻国相望，鸡犬之声相闻，民至老死不相往来。</p> 【第八十一章】信言不美，美言不信；善者不辩，辩者不善；知（zhì）者不博，博者不知（zhì）。圣人不积，既以为人，己愈有；既以与人，己愈多。天之道，利而不害。圣人之道，为而不争。</p> 《道德经》译文精简版 2025-03-20T00:00:00+00:00 第一章道可道（可以语言交流的道），非常道（非真正意义上的道）；名可名（可以明确定义的名），非常名（非真正意义上的名）。无名天地之始（天地在开始时并无名称），有名万物之母（名只是为了万物的归属）。故常无欲以观其妙（因此常用无意识以发现其奥妙），常有欲以观其徼（常用有意识以归属其范围）。两者同出异名（两种思维模式同出自一个地方但概念却不相同），同谓玄之又玄（这就是玄之又玄的玄关窍）。众妙之门（它是打开一切奥妙的不二法门）。</p> 第二章天下皆知美之为美（天下皆知美之所以为美），斯恶已（是因为丑恶的心灵在作崇）；皆知善之为善（皆知善之所以为善），斯不善已（是因为不善的意念在作怪）。故有无相生（因此而产生了有无相生）、难易相成（难易相成）、长短相形（长短相形）、高下相倾（高下相倾）、音声相和（音声相和）、前后相随（前后相随等各种患得患失的主观意识）。是以圣人（但是圣人），处无为之事（处于无区别心之无为境界），行不言之教（教化众生于不言之中），万物作焉而不辞（顺应万物的发展规律而不横加干涉）。生而不有（生养万物而不据为己有），为而不恃（竭尽全力而不自恃已能），功成而弗居（功成业就而不居功自傲）。夫为弗居（正因为他不居功自傲），是以不去（所以他不会失去什么）。</p> 第三章不尚贤（不刻意招贤），使民不争（使民众不去争名）；不贵难得之货（不稀罕难得之货），使民不为盗（使民众不为盗）。不见可欲（不见引发欲望的根源），使心不乱（就不会产生动乱的动机）。是以圣人之治（所以圣人的治理方法是）：虚其心、实其腹（普及虚心、养身的道理），弱其智、强其骨（宣传弱智、强骨的好处），常使民无知无欲（常使人民深刻感悟无知无欲的益处），使夫知者不敢为也（使那些自作聪明的人无用武之地）。为无为（以无为的境界处理政务），则无不治（国家就没有治理不好的理由）。</p> 第四章道冲（道似一个器皿），似万物之宗（好像万物的根源），渊兮（它浩瀚无边啊），而用之或不盈（永远取之不尽）。挫其锐（压制锋芒），解其纷（解脱纷扰）；和其光（和顺光辉），同其尘（混同尘垢）。湛兮（高深莫测啊），似若存（好像无处不在）。吾不知谁之子（我虽然不知它的来源），象帝之先（但它却先于上帝）。</p> 第五章天地不仁（天地超越仁的概念），以万物为刍狗（任凭万物像草狗那样自生自灭）；圣人不仁（圣人超越仁的概念），以百姓为刍狗（任凭百姓自作自息）。天地之间（天地之间的一切生命），其犹橐龠乎（犹如风箱一样），虚而不淈（虚空但无穷尽），动之愈出（越动付出愈多）。多言数穷（言多必然有失），不如守中（不如抱心守一）。</p> 第六章谷神不死（掌握采集大道能量的方法就可以长寿），是谓玄牝（就好比掌握了复制生命的方法）。玄牝之门（复制生命的不二法门），是谓天地根（是与天地同寿的根本）。绵绵若存（绵绵不断的生命形式就是这样存在的），用之不勤（大道的能量是用之不竭的）。</p> 第七章天长地久（天长地久）。天地之所以能长且久者（天地之所以能长久），以其不自生（因为它不为自己而生），故能长生（所以能长生）。是以圣人（因此圣人），后其身而身先（因为谦让反而获得人民的拥戴），外其身而身存（置之身外反而让人民依赖他的存在），非以其无私邪（难道不是这种无私的精神）？故能成其私（反而成全了圣人的理想吗）。</p> 第八章上善若水（上等的善就如水一样）。水善（水善的表现形式是）：利万物而不争（滋养万物而不争功），处众人之所恶（甘居众人之所唾弃），故几于道（所以水最接近于大道）。居善地（起居善于选择吉地），心善渊（心态善于融入平静），与善仁（交流善于把握仁爱），言善信（言语善于表达诚信），正善治（政见善于治理国家），事善能（处事善于发挥能量），动善时（行动善于把握时机）。夫唯不争（惟有像水这样不争），故无尤（所以才能万事无忧）。</p> 第九章持而盈之（财物执持盈满），不如其已（不如适可而止）；揣而锐之（铁器磨得锐利），不可长保（不可长期保存）；金玉满堂（金玉堆满堂屋），莫之能守（不知谁人能守）；富贵而娇（富贵而生骄横），自贻其咎（那是自找麻烦）。功成身退（功成名就身退），天之道（才是自然之道）。</p> 第十章载营魄抱一（精神与形体统一），能无离乎（能永远不分离吗）？专气致柔（结聚精气以致柔和），能婴儿乎（能像初生的婴儿吗）？涤除玄监（洗涤心灵之镜），能无疵乎（能没有瑕疵吗）？爱民治国（爱护百姓治理国家），能无为乎（能顺应自然吗）？天门开阖（感官自然开启），能无雌乎（能不被引诱吗）？明白四达（理事明白通达），能无知乎（能没有成见吗）？生之畜之（创造并养育万物的大道），生而不有（创造万物而不占为己有），为而不恃（无所不能而不自恃有功），长而不宰（左右万物而不任意宰割），是谓玄德（这就是恩泽天下的玄德）。</p> 第十一章卅辐共一毂（卅根辐条围成一个轱辘），当其无有车之用（因为中间有空车才能行进）。然埴以为器（燃烧粘土使其成为器皿），当其无有器之用（因为中间有空器皿才能容纳）。凿户牖以为室（开凿门窗建造居室），当其无有室之用（因为中间有空居室才有光明）。故有之以为利（有形的东西之所以被人们利用），无之以为用（是因为看不见的无形在起作用）。</p> 第十二章五色令人目盲（贪图美色令人看不清丑恶）；五音令人耳聋（喜闻顺音令人听不到忠言）；五味令人口爽（美味佳肴令人品不了疾苦）；驰骋田猎令人心发狂（驰骋田猎令人心狂意躁）；难得之货令人行妨（难得之货令人图谋不轨）。是以圣人之治（因此圣人治理国家），为腹不为目（重视内在的充实而放弃表面的愉悦），故去彼取此（所以知道如何舍得）。</p> 第十三章宠辱若惊（宠辱若惊），贵大患若身（贵大患若身）。何谓宠辱若惊（什么叫宠辱若惊）？辱为下（把荣辱看得比生命都重要），得之若惊（得到了无比惊喜），失之若惊（失去了无比惊恐）。是谓宠辱若惊（这就叫宠辱若惊）。何谓贵大患若身（什么叫贵大患若身）？吾所以有大患者（我所以有强烈患得患失的心态），为吾有身（因为我有自我的观念），及吾无身（如果我抛开自我），吾有何患（我还有什么理由患得患失）。故贵以身为天下（所以重视自身为天下的人），则可寄于天下（才可以把天下寄于他）；爱以身为天下者（爱惜自身为天下的人），乃可以托于天下（才可以把天下托付给他）。</p> 第十四章视之不见（看不到图象），名曰夷（称着夷）；听之不闻（听不到声音），名曰希（称着希）；抟之不得（触不到形体），名曰微（称着微）。此三者不可致诘（此无色、无声、无形之物无法用语言描述），故混而为一（只能称它为阴阳未判之混元一气）。其上不谬（它的上面不见光明），其下不昧（它的下面不见黑暗），绳绳不可名（实在是无法给它下定义），复归于无物（还是把它复归于无物吧）。是谓无状之状（这应该是无状态之状态），无物之象（无物象之物象），是谓恍惚（这就是似无似有的恍惚），迎之不见其首（往前追溯不知何时开始），随之不见其后（往后跟随不知何时结束）。执古之道（掌握上古的自然之道），以御今之有（以驾御今天的生命之有），以知古始（以感知上古的来龙去脉），是谓道纪（这就是自然之道的纲纪）。</p> 第十五章古之善为道者（古时善于修道的人），微妙玄通（见解微妙而深远通达），深不可识（给人一种高深莫测的感觉）。夫唯不可识（夫惟恐言不达意），故强为之容（故努力为之形容）：豫兮若冬涉川（开始学道者谨慎的象严冬过河），犹兮若畏四邻（尤其惧怕邻里的干扰），俨兮其若客（严肃的好象虔诚的客人）。涣兮若冰之将释（继而他的性格会变的洒脱无羁涣然冰释），敦兮其若朴（品质会变的敦厚诚恳朴实无华），旷兮其若谷（心胸会变的旷达开朗虚怀若谷），浑兮其若浊（意识会经历浑浊及混乱的考验）。孰能浊以止（如何将这种混乱的杂念止住呢）？静之徐清（把心静下来漫漫就清澈了）。孰能安以久（什么方法能保持安静状态长久）？动之徐生（感悟静极生动带来的生机）。保此道者不欲盈（保持这种方法修道的人不会骄傲自满），夫唯不盈（正因为他不会骄傲自满），故能敝而新成（所以才能敝弃陈旧获得更新）。</p> 第十六章至虚极（修道进入虚无至极的意境），守静笃（安守宁静气定神闲）。万物旁作（万物在时空的隧道中行进），吾以观其复（我可以反复观察他们的循环）。夫物芸芸（天地万物芸芸众生），各复归其根（各自都要归于它们的因果）。归根曰静（看到因果可以说是静的作用），静曰复命（只有静才能了解生命的真谛）。复命曰常（生命的真谛就是变化的规律），知常曰明（了解变化规律才算通晓明白）。不知常（如果不知道变化规律），忘作凶（妄作非为自然带来凶险）。知常容（知道变化规律才能包容一切），容乃公（包容一切才能公正豁达），公乃全（公正豁达才能完整周全），全乃天（完整周全才能符合自然），天乃道（符合自然就是遵循大道），道乃久（遵循大道才能长治久安），没身不殆（终身都不会感觉到不妥）。</p> 第十七章太上，不知有之（最好的统治者，人民并不知道他的存在）。其次，亲之誉之（其次的，人民近而赞美他）。其次，畏之（再次的，人民畏惧他）。其下，侮之（更次的，人民轻蔑他）。信不足焉（信用不足的君主），有不信焉（自然有不信任他的臣民）。犹兮其贵言（谨慎做到不随意发号施令），功成事遂（帮助人民实现心愿），百姓皆谓：“我自然”（百姓都说：“我们本来就是这样的”）。</p> 第十八章大道废（大道废除），有仁义（自然出现仁义）；智慧出（智慧频出），有大伪（自然混杂大伪）；六亲不和（六亲不和），有孝慈（自然彰显孝慈）；国家昏乱（国家昏乱），有忠臣（自然产生忠臣）。</p> 第十九章绝圣弃智（崇高的圣贤志士不用奸诈治国），民利百倍（人民自然可以获得百倍的利益）；绝仁弃义（崇高的仁爱之士不搞义气用事），民复孝慈（人民自然能恢复忠孝仁慈之心）；绝巧弃利（崇高的能工巧匠不去争夺名利），盗贼无有（盗贼自然不会刻意打他的主意）。此三者以为文不足（仅此三者作为法则是远远不够的），故另有所属（所以另外还须心有所属）：见素抱朴（保持纯朴的心态），少私寡欲（减少自私的欲望）。绝学无忧（这就是崇高而快乐无忧的学问）。</p> 第二十章唯之与阿（真理与谬误），相去几何（相差多少）？美之与恶（真善美与假恶丑），相去何若（相差又在那里）？人之所畏（人们所畏惧的东西），不可不畏（也畏惧人吗）？荒兮（浩瀚的荒漠啊），其未央哉（又有多少悬而未决的道理）。众人熙熙（众人都喜欢熙熙攘攘凑热闹），如享太牢（比如去参加盛大的祭祀活动），如春登台（比如春天登临楼台远眺美景）。我独泊兮其未兆（我们确淡泊恬静好象未开窍），如婴儿之未孩（如婴儿刚出世还没有学会笑）。乘乘兮（随风漂泊啊），若无所归（仿佛找不到归宿）。众人皆有余（众人都希望自己富贵有余），而我独若遗（而我们却希望自己扔掉包袱）。我愚人之心也哉（我们这种愚人的心灵啊），沌沌兮（多么象混沌无知啊）。俗人昭昭（世俗之人看上去都能明明白白的事情），我独昏昏（惟独我们得道之士仿佛昏昏沉沉）。俗人察察（世俗之人看上去都能清清楚楚的事情），我独闷闷（惟独我们得道之士仿佛蒙在鼓里）。众人皆有以（众人皆有远大的志向），而我独顽且鄙（惟独我们冥顽不化而且鄙陋寡闻）。泽兮其若海（沉静啊就像地平线上的大海），飂兮若无止（却有着无法遏止的生命动力）。我独欲异于人（我们与众人不同的理由），而贵食母（是因为推崇从道中得到养份）。</p> 第二十一章孔德之容（天人合一的通道可以容纳万众的意识），唯道是从（只有符合大道才能被认从）。道之为物（道作为未知世界的事物规律），唯恍唯惚（只能以恍恍惚惚的形式存在）。惚兮恍兮（在这种亦真亦幻的意境中），其中有象（能看到万物的景象）；恍兮惚兮（在这种似有似无的意境中），其中有物（能感知万物的本性）；窈兮冥兮（意识深远冥灭自性），其中有精（就能把握其中的精华）。其精甚真（其精华的真实程度毋庸置疑），其中有信（这就是你确信无疑的感悟）。自古及今（从古至今），其名不去（这种悟道的方法就没有失去过），以说众甫（用它可以了解众生万物的规律）。吾何以知众甫之然哉（我何以知道众生万物的规律）？以此（就是用这种方法感悟的）。</p> 第二十二章曲则全（弯曲形成了最完美的世界），枉则直（大的弯曲则象是一条直线），洼则盈（身置低洼处才会获得盈满），敝则新（鄙弃旧观念才能推陈出新），少则得（爱好越少越容易获得感悟），多则惑（爱好越多反而会感到迷惑）。是以圣人抱一（所以圣人悟道会专一致志），为天下式（这样才能成为天下的榜样）。不自见故明（不自持己见反能明白事理）；不自是故彰（不自以为是反能是非彰显）；不自伐故有功（不自负蛮干反能获得成功）；不自矜故长（不自认圣贤反能成为首领）。夫唯不争（正因为你与世无争），故天下莫能与之争（所以天下反而没人与你相争）。古之所谓“曲则全”者（古人所言“曲则全”者），岂虚言哉（怎么会是虚言呢）？诚全而归之（诚信此道者天下将归属他）。</p> 第二十三章希言自然（少发号令也是符合自然的）。飘风不终朝（狂风不会坚持一上午），骤雨不终日（骤雨不会坚持一整天）。孰为此者（谁会这样大发雷霆）？天地（这是天地的杰作）。天地尚不能久（天地的狂暴尚不能长久保持），而况于人乎（又何况于人呢）？故从事于道者（所以生活在自然规律中的人们），道者同于道（修道者喜欢同道在一起）；德者同于德（有德者喜欢同德在一起）；失者同于失（失落者喜欢同失落在一起）。同于道者（于道相同的人），道亦乐得之（道也愉快地接纳）；同于德者（于德相同的人），德亦乐得之（德也愉快地接纳）；同于失者（于失落相同的人），失亦乐得之（失落也愉快地接纳）。信不足焉（诚信不足的人），有不信焉（自然有不信他的人）。</p> 第二十四章跂者不立（脚不粘地不晓立者感受），跨者不行（骑人肩膀不知行者甘苦）。自见者不明（自我成见不能明白事理），自是者不彰（自以为是不能彰显智慧），自伐者无功（自我蛮干只能无功而返），自矜者不长（自恃圣贤不能成为首领）。其在道也（这样的人如果混入道中），曰余食赘行（必然犯余食赘行的毛病）。物或恶之（有人或许厌恶这种观点），故有道者不处（但得道者会超越这种境界）。</p> 第二十五章有物混成（有一种物质混然而成），先天地生（先于天地产生）。寂兮廖兮（寂静啊无形啊），独立而不改（独立存在而永恒不变），周行而不殆（周而复始而不会殆尽），可以为天下母（可以认为它是天下万物的本源）。吾不知其名（我不知它叫什么名字），字之曰 “道” （就送它一个字叫“道” ），强为之名曰“大” （勉强为它起了一个名叫“大” ）。大曰逝（它可以说是遥不可及的过去和未来），逝曰远（遥不可及的过去和未来也可以说是无比深远），远曰反（知道它的深远是因为能了解它周而复始的缘故）。故道大（所以说道是伟大的）、天大（天是伟大的）、地大（地是伟大的）、人亦大（人也是伟大的），域中有四大（宇宙中有四个伟大），而人居其一焉（而人也占居其中之一）。人法地（人尊循于地的法则），地法天（地尊循于天的法则），天法道（天尊循于道的法则），道法自然（道尊循于自然的法则）。</p> 第二十六章重为轻根（稳重是飘然的根基），静为躁君（宁静是狂躁的主宰）。是以圣人（所以圣人），终日行不离辎重（终日行进而不离载重车辆）。虽有荣观（虽有豪华生活），燕处超然（却能超然物外）。奈何万乘之主（无奈有一些拥有万辆马车的国主），而以身轻天下（只知满足自身欲望而轻天下社稷）。轻则失本（因轻浮而失去道德跟本），躁则失君（因狂躁而失去主宰地位）。</p> 第二十七章善行无辙迹（善于行动不会留下痕迹），善言无瑕谪（善于言谈不会留下话柄），善数不用筹策（善于算术不用筹码工具），善闭无关楗则不可开（善于关闭无需门闩顶杠也无法打开），善结无绳约则不可解（善于捆绑不用绳索制约也无法解脱）。是以圣人（因此圣人），常善救人（常常善于拯救世人），故无弃人（所以没有人被遗弃）；常善救物（常常善于拯救万物），故无弃物（所以没有物被遗弃）。是谓袭明（这是传承大道之明）。故善人者（所以善于拯救世人的人），不善人之师（是不善于此道者的老师）；不善人者（不善于此道者的人），善人之资（是善于此道者的资源）。不贵其师（不尊重这样的老师），不爱其资（不爱惜这样的资源），虽智大迷（虽有智慧却身在迷中）。是谓要妙（这是善人之道的要妙）。</p> 第二十八章知其雄（知道阳刚的雄健），守其雌（却甘愿安守雌柔），为天下溪（好比天下的溪流）。为天下溪（成为天下的溪流），常德不离（自然之德陪伴左右），复归于婴儿（这样就能回复婴儿般的纯真自然）。知其白（知道光明在那里），守其黑（却安于暗昧之处），为天下式（这是天下人的榜样）。为天下式（成为天下人的榜样），常德不忒（自然之德不会失却），复归于无极（这样就能回复到最初的无极状态）。知其荣（知道荣耀的珍贵），守其辱（却能守得住谦卑），为天下谷（就像天下的虚谷一样）。为天下谷（天下的虚谷容纳万物），常德乃足（自然之德才能富足），复归于朴（这样就能回复到返朴归真的境界）。朴散则为器（这种品质的人到哪里都是成大器者），圣人用之（圣人如果用他），则为官长（会让他做领导），故大制不割（所以美好的制度不会割舍他的）。</p> 第二十九章将欲取天下而为之（将征服天下定为人生的目标），吾见其不得已（我预见他不可能获得成功）。天下神器（世界是神圣的），不可为也（不可能让人为所欲为）。为者败之（为所欲为者必败），执者失之（执迷不悟者必失）。故物或行或随（万物有独行的也有群随的），或嘘或吹（有热血的也有冷血的），或强或羸（有强大的也有羸弱的），或载或隳（有天上飞的也有水中游的）。是以圣人去甚（所以圣人去除一切极端的念想），去奢（去除一切不切实际的奢望），去泰（去除一切过度的要求）。</p> 第三十章以道佐人主者（以道辅佐人的主观意识），不以兵强天下（不以武力强行征服天下），其事好还（这样的结果有好报应）。师之所处（因为军队驻扎之处），荆棘生焉（田地荒芜杂草丛生）。大军之后（大的战役结束之后），必有凶年（必定带来凶灾之年）。善者果而己（善于把握结果者会适可而止），不敢以取强（不敢用武力去强硬获取胜利）。果而勿矜（达到目的不要自夸自大），果而勿伐（达到目的不要盲目自负），果而勿骄（达到目的不要骄傲自满），果而不得已（达到目的要认为这是不得已的），果而勿强（达到目的不要肆意逞强）。物壮则老（事物发展到壮盛则是衰老的开始），是谓不道（这是不以人的意志为转移的规律），不道早已（不遵从这个规律难免会过早衰亡）。</p> 第三十一章夫佳兵者（最好的军队），不祥之器（是国家预防不测的机器）。物或恶之（有人或是厌恶这种说法），故有道者不处（所以有道者会超越凡人的境界）。君子居则贵左（君子平时会强化士兵战斗的意志），用兵则贵右（而在战争时却会强调冷静）。兵者（军队），不祥之器（是国家预防不测的机器），非君子之器（不是君子一个人的机器），不得已而用之（只有在不得已时才被迫使用）。銛袭为上（依仗锋利的兵器偷袭为上），胜而不美（即使是赢得胜利也不光彩）。而美之者（而喜欢用这种战术赢得胜利的人），是乐杀人（往往是乐于杀人的刽子手）。夫乐杀人者（一个乐于杀人的刽子手），则不可以得志于天下（是不可能实现统一天下的志向的）。吉事尚左（喜报可以鼓舞士气），凶事尚右（厄报可以冷静思考）。偏将军居左（偏将军的使用应当侧重勇猛），上将军居右（上将军的使用应当侧重冷静），言以丧礼处之（战斗的动员令要站在视死如归的高度）。杀人之众（面对阵亡的众多将士），以悲哀泣之（要以悲哀的心情来缅怀他们）。战胜（取得战争的胜利之后），以丧礼处之（要以办丧事的礼节来庆祝胜利）。</p> 第三十二章道常无名（大道常在无有之间）。朴虽小（淳朴的本源虽然微小），天下不敢臣（天下却没有力量能臣服它）。侯王若能守之（统治者若能坚持这个真理），万物将自宾（天下万物必将自然归顺他）。天地相合以降甘露（天地之气相合以降甘露），民莫之令（不可能顺从于谁的命令），而自均（而它自己确能分布均匀）。始制有名（万物开始时就有了秩序和名分），名亦既有（名分既然以有），夫亦将知之（就应该知道它的自然规律），知之所以不殆（知道它的自然规律所以不会有危险）。譬道之在天下（譬如道在天下的自然规律），犹川谷之与江海（好象溪流之水汇集与江海）。</p> 第三十三章知人者智（知道别人的优缺点是智慧），自知者明（知道自己的优缺点是贤明）。胜人者有力（能战胜别人的人有一定的实力），自胜者强（能战胜自己的人坚强无比）。知足者富（知道什么是满足的人富裕），强行者有志（克服困境勇敢前行的人有志气）。不失其所者久（不迷失自己前进方向的人能够长久），死而不亡者寿（形体消失而精神永存的人才叫长寿）。</p> 第三十四章大道泛兮（大道广泛的能量啊），其可左右万物（可以左右万物）。恃之以生而不辞（但它恃侯万物之生却不宣扬），功成不名有（功成名就之后不图虚名），衣养万物而不为主（护荫万物而不思主宰）。常无欲（常用无欲的方法获得智慧），可名于小（就可以小有名气）；万物归焉而不为主（万物归顺之后而不思主宰），可名为大（就可以获得大成功）。是以圣人终不为大（所以圣人始终不自以为大），故能成其大（因此能成就其伟大的事业）。</p> 第三十五章执大象（拥有符合大道自然之象的地方），天下往（是天下人向往的地方）。往而不害（在她那里不会遭到自然的伤害），安平泰（是因为她具备了安详、平和、舒泰的条件）。乐与饵（快乐的民风与诱人的环境），过客止（可以留住匆匆过客的脚步）。道之出口（这些优点如果用语言来表达），淡乎其无味（那就平淡无味了）。视之不足见（因为你看到的不是她的全部），听之不足闻（听到的也不是她的全部），用之不可既（但享受起来却受益无穷）。</p> 第三十六章将欲翕之（将欲马上收敛的），必固张之（必是原有张之过度的）；将欲弱之（将欲逐渐削弱的），必固强之（必是原有强制过头的）；将欲废之（将欲立即废除的），必固兴之（必是原有兴奋超前的）；将欲夺之（将欲重新夺取的），必固与之（必是原有被迫给予的）。是谓微明（这是微妙简明的道理），柔弱胜刚强（柔弱胜过刚强）。鱼不可脱于渊（鱼儿离不开水），国之利器不可以示人（镇国之宝不可以示人）。</p> 第三十七章道常（道的常识），无为而无不为（无为的境界造就无所不为的功绩）。侯王若能守之（统治者若能遵守这个规律），万物将自化（万物将自然归化）。化而欲作（在归化的过程中难免欲望发作），吾将镇之以“无名之朴” （这时可以用我的“无名之朴”去除杂念）。镇之以“无名之朴” （用我的“无名之朴”去除杂念），夫亦将不欲（他们就会克服欲望），无欲以静（没有欲望就可以静下心来），天下将自定（这样天下将自然安定）。</p> 第三十八章上德不德（品德高尚的人没有德的概念），是以有德（这是因为他从来没有离开德）。下德不失德（品德一般的人表现形式上的德），是以无德（实际上是一种没有德的表现）。上德无为而无以为（品德高尚者顺应自然而不自以为然），下德为之而有以为（品德一般者做了什么就以为了不起）。上仁为之而无以为（大仁爱者表现的仁爱是不自觉的），上义为之而有以为（义气用事的人就有明确的目的性），上礼为之而莫之应（行大礼者如果得不到对方的相应），则攘臂而扔之（则恨不得抓住胳臂使人强从）。故失道而后德（所以失去大道的人应该遵守德之规范），失德而后仁（失去德之规范的人应该具有仁爱之心），失仁而后义（失去仁爱之心的人应该讲点道义），失义而后礼（失去道义的人应该懂得社会的礼节）。夫礼者（如果连社会的礼节都失去了），忠信之薄（忠信之薄就可想而知了），而乱之首（它是引发一切动乱的罪魁祸首）。前识者（有先见之明的人），道之华（知道社会上一旦礼节繁多），而愚之始（那么愚昧也就随之而至）。是以大丈夫处其厚（因此大丈夫宁愿处于敦厚淳朴之乡），不居其薄（不愿居住于忠信浅薄之处）。处其实（宁愿于朴实无华者为邻），不居其华（也不愿居住在礼节繁多的闹市）。故去彼取此（所以有智慧的人知道如何取舍）。</p> 第三十九章昔之得一者（昔日获得阴阳未判混元一气者）：天得一以清（天得到混元一气可以清澈）；地得一以宁（地得到混元一气可以宁静）；神得一以灵（元神得到混元一气可以有灵性）；谷得一以盈（川谷得到混元一气可以盈满）；万物得一以生（万物得到混元一气可以生生不息地繁衍）；侯王得一以为天下正（统治者得到混元一气可以号令天下）。其致之也（因此我们可以得出这样的结论）：天无以清将恐裂（天没有清澈必将崩裂）；地无以宁将恐发（地没有安宁必将动乱）；神无以灵将恐歇（元神没有灵性必将休亡）；谷无以盈将恐竭（川谷没有盈满必将枯竭）；万物无以生将恐灭（万物不能生息必将绝灭）；侯王无以高贵将恐蹶（统治者失去高贵必遭颠覆）。故贵以贱为本（所以贵以贱为根本），高以下为基（高以下为根基）。是以侯王自谓孤寡不谷（所以侯王自称“孤”、“寡”、“不谷” ），此其以贱为本邪（以此来表明他以贱为本的态度啊）。非乎（难道不是这样的吗）？故至誉无誉（所以最高的荣誉无需赞誉）。不欲琭琭如玉（不要认为自己是一块美玉），珞珞如石（把自己看成一块石头）。</p> 第四十章反者（物极必反），道之动（是运动的规律）。弱者（能把握规律的弱点），道之用（是对道的理解与应用）。天下万物生于有（对天下万物的认知产生于有形的运动），有生于无（而有形的运动开始于无形的积蓄）。</p> 第四十一章上士闻道（上士闻听悟道的方法），勤而行之（会勤奋学习马上行动）；中士闻道（中士闻听悟道的方法），若存若亡（会将信将疑是懂非懂）；下士闻道（下士闻听悟道的方法），大笑之（会嗤之以鼻哈哈大笑）。不笑不足以为道（这种人不笑不足以证明大道的可贵）。有建言者（有《建言者》记载）：明道若昧（光明的大道好似昧暗），进道若退（前进的大道好似后退），夷道若堆（平坦的大道好似崎岖）。上德若谷（上德的境界好似虚谷），大白若辱（最洁白的好似有暇疵），广德若不足（最广大德恍似不足够），建德若偷（修德的过程好似怠惰），质真若渝（质朴纯真好似不坚定）。大方无隅（远大的目标落实于障碍的跨越），大器晚成（贵重的器皿成型于精细的雕琢），大音希声（动听的音乐来源于单声的组合），大象无形（伟大的形象形成于无形的感化）。道隐无名（大道隐藏在无名事物中），夫唯道（只有遵循大道规律的人），善贷且成（才能善始善终并且成功）。</p> 第四十二章道生一（自然生就阴阳未判一气混元），一生二（一气混元激活了时间与空间），二生三（在时间与空间中产生了能量），三生万物（能量的互相转换产生了万物）。万物负阴而抱阳（万物都有负阴而抱阳的特性），冲气以为和（阴阳互动是走向和谐的根本）。人之所恶（人们所厌恶的），唯孤寡不谷（莫过于“孤”、“寡”、“不谷” ），而侯王以为称（而侯王却把它作为自己的称谓）。故物或损之而益（因此万物或是因为减损反而获得增加），或益之而损（或是因为增加反而导致减损）。故人之所教（前人的谆谆教导），我亦教之（我们也用来教育后人）。强梁者不得其死（努力培养栋梁之才的人精神是不死的），我将以为教父（我们将以他们作为学习的榜样）。</p> 第四十三章天下之至柔（天下最柔善的），驰骋天下之至坚（驾御天下最坚毅）。无有（无形有质的），入于无间（进入不开窍的空间），吾是以知无为之有益（我从这里感知无为的益处）。不言之教（无法用言传的教育方法），无为之益（无为状态所带来的益处），天下希及之（天下是很少有人明白的）。</p> 第四十四章名与身孰亲（虚名与生命哪样更亲）？身与货孰多（生命与利益哪样贵重）？得与亡孰病（贪得名利与放弃生命哪样是病态）？甚爱必大费（过于爱惜虚名必定大费其神）。多藏必厚亡（过于收敛财物必定大伤其身）。知足不辱（知道满足便不会受辱），知止不殆（适可而止便不会遭殃），可以长久（这样才可以保持长久）。</p> 第四十五章大成若缺（完满的东西似有欠缺），其用不弊（但它的作用不会衰竭）；大盈若冲（充盈的东西似有空虚），其用不穷（但它的作用不会穷尽）。大直若屈（正直的东西似有弯曲），大巧若拙（灵巧的东西好似笨拙），大辩若讷（卓越的辩才好似木讷）。躁胜寒（运动可以战胜寒冷），静胜热（宁静可以战胜炎热），清静为天下正（清静无为可以治理天下）。</p> 第四十六章天下有道（天下拥有自然和谐之道），却走马已粪（就会看见快马在田间劳作）；天下无道（天下失去自然和谐之道），戎马生于郊（就会看见戎马在郊外生产）。祸莫大于不知足（最大的灾祸莫过于不知足），咎莫大于欲得（最大的危害莫过于贪得无厌）。故知足之足（所以以知足为满足的人），常足矣（永远是满足的）。</p> 第四十七章不出户（不出门户），知天下（就能够推知天下的事理）；不窥牖（不望窗外），见天道（就可以认识日月星辰运行的自然规律）。其出弥远（他向外奔逐得越远），其知弥少（他所知道的道理就越少）。是以圣人不行而知（有“道”的圣人不出行却能够推知事理），不见而明（不窥见而能明了“天道”），不为而成（不妄为而可以有所成就）。</p> 第四十八章为学者日益（学习有一个日渐结累的过程），为道者日损（证道有一个日渐淡忘的过程）。损之又损以至于无（当你的意识无需依赖任何提示的时候），为无为（这种境界就叫无为），而无不为（它凝聚着无所不能的大智慧）。取天下常以无事（这样的人赢得天下是自然的），及其有事（如果依然放不下学习过的知识），不足以取天下（就不足以赢得天下）。</p> 第四十九章圣人无常心（圣人没有自己的成见之心），以百姓之心为心（以百姓的心愿为自己的心愿）。善者善之（善良的人用善心去对待），不善者亦善之（不善良的人也用善心去对待），德善（从而收获善良的果子）。信者信之（诚信的人用诚信去对待），不信者亦信之（不诚信的人也用诚信去对待），德信（从而收获诚信的果子）。圣人在（有圣人的领导），天下翕翕（天下必然和顺）。为天下浑其心（为天下调和统一的精神），百姓皆注其耳目（百姓都会注视他的声音和目光），圣人皆孩之（圣人也把百姓当作自己的孩子）。</p> 第五十章出生入死（从生到死），生之徒十有三（活人有四肢九窍）；死之徒十有三（死人有四肢九窍）；人之生动之死地（活生生的人死于非命），亦十有三（也有四肢九窍）。夫何故（区别在哪里）？以其生生之厚（就是对生命的感悟境界）。盖闻善摄生者（传说善于把握生命的人），陆行不遇兕虎（在陆地上行走不会遇到犀牛和老虎），入军不被甲兵（进入军队不用被上盔甲和带上兵器）。兕无所投其角（犀牛没有目标用它的犄角），虎无所措其爪（老虎没有目标用它的利爪），兵无所容其刃（敌人没有目标用他的兵刃）。夫何故（为什么有这样的结果）？以其无死地（就是他没有进入必死之地）。</p> 第五十一章道生之（大道规律创造了生命），德畜之（大德规范维护了发展），物形之（物种的差异形成了各自的特点），势成之（团队的优势是它们成功的关键）。是以万物（所以万物的本能意识），莫不尊道而贵德（莫不尊崇大道而且器重大德）。道之尊（大道被尊崇），德之贵（大德被器重），夫莫之命（不是听谁的命令），而常自然（而是自然的规律）。故道生之（所以大道自然创造了生命），德畜之（大德自然维护了发展）。长之育之（道生长万物德培育万物），亭之毒之（道丰满万物德成熟万物），养之覆之（道滋养万物德维护万物）。生而不有（它们生育万物而不占为己有），为而不恃（无所不为而不自恃有功），长而不宰（统领万物而不任意宰割），是谓玄德（这就是恩泽天下的玄德）。</p> 第五十二章天下有始（天下万事都有它们的初始），以为天下母（可以说是天下万事的起点）。既得其母（既然知道天下万事的起点），以知其子（就能知道天下万事的结果）；既知其子（既然知道天下万事的结果），复守其母（再反过来印证万事的起点），没身不殆（这样做一生都不会有闪失）。塞其悦（堵塞感官之窍），闭其门（封闭欲望之门），终身不勤（终身不会疲惫）。开其悦（开启感官之窍），济其事（增添纷扰之事），终身不救（终身不可救药）。见常曰明（能预见规律可以说是圣明），守柔曰强（能保持柔和可以说是坚强）。用其光（用其所掌握的智慧之光），复归其明（复归万事万物光明的前景），无遗身殃（就不可能给自己留下祸殃），是谓袭常（这是传承下来的悟道方法）。</p> 第五十三章使我介然有知（假若我们稍微有一点智慧），行于大道（就会知道行于大道的人），唯施是畏（最畏惧的就是走上邪道）。大道甚夷（大道是那样的平坦），而民好径（而人们却偏行邪经）。朝甚除（朝政腐败已极），田甚芜（农田十分荒芜），仓甚虚（仓库非常空虚）。服文彩（还穿着锦衣华服），带利剑（腰佩锋利的宝剑），厌饮食（厌烦过饱的饮食），财货有余（贪得过多的钱财货物），是谓盗夸（这就是大强盗做法）。非道也（多么无道啊）。</p> 第五十四章善建者不拔（善于建立德性的人坚毅不拔），善抱者不脱（善于抱持大道的人永不松脱），子孙以祭祀不辍（这是子孙得以祭祀不绝的榜样）。修之身（用这样的榜样来修身），其德乃真（他的德行就会返朴归真）；修之家（用这样的榜样来齐家），其德乃余（这个家庭的德行就会充实有余）；修之乡（用这样的榜样来建乡），其德乃长（这个乡的德行就会传颂久长）；修之国（用这样的榜样来治国），其德乃丰（这个国家的德行就会丰富盈满）；修之天下（用这样的榜样来平天下），其德乃普（天下的德行就会像阳光那样普照万物）。故以身观身（所以从一个人的身上可以观察一个人的德行），以家观家（以一个家庭的德行可以观察一个家庭的情形），以乡观乡（以一个乡的德行可以观察一个乡的情形），以国观国（以一个国家的德行可以观察一个国家的情形），以天下观天下（以天下的德行可以观察天下的情形）。吾何以知天下然哉（我凭什么知道天下必然的结果啊）？以此（就是以此推断的）。</p> 第五十五章含德之厚（含德深厚的人），比于赤子（意境犹如婴儿）。毒虫不螯（毒虫不会螯他），猛兽不据（猛兽不会扑他），攫鸟不搏（禽鸟不会抓他）。骨弱筋柔而握固（骨弱筋柔但能握紧拳头），未知牝牡之合而朘怒（不知道男女交合但生殖器却能勃起），精之至（这是精气充足所至）。终日号而不嗄（终日号哭但不会造成嗓音沙哑），和之至（这是和气充足所至）。知和曰常（知道中和的道理称其永恒），知常曰明（知道永恒的道理则是圣明），益生曰祥（用和气益生可以说万事吉祥），心使气曰强（有心硬要达到目的可以说是逞强）。物壮则老（万物强行壮大必然加速衰老），谓之不道（可以说这不是大道自然规律），不道早已（不合规律的事不能长久）。</p> 第五十六章知者不言（心灵深处的感悟真正明白的人是不妄言的），言者不知（妄言的人不是真正明白的人）。塞其悦（堵塞其感官之窍），闭其门（关闭其欲望之门），挫其锐（不露锋芒），解其纷（解脱纷扰），和其光（顺和光辉），同其尘（混同尘垢），是谓玄同（这就是与道大同的玄妙）。故不可得而亲（因此既不可能得到他特别的亲爱），不可得而疏（也不可能得到他特别的疏远）；不可得而利（既不可能得到他特别的利益），不可得而害（也不可能得到他特别的危害）；不可得而贵（既不可能得到他特别的敬重），不可得而贱（也不可能得到他特别的排斥）。故为天下贵（所以这样的人是天下的贵人）。</p> 第五十七章以正治国（以正大光明的政策治理国家），以奇用兵（以出奇制胜的方法用兵打仗），以无事取天下（以自然无为的意境赢得天下）。吾何以知其然哉（我何以知道应该这样做呢）？以此（是根据以下推断的）：天下多忌讳（天下禁令越多），而民弥贫（民众就会越穷）；民多利器（民众多有利器），国家滋昏（国家治安昏乱）；人多伎巧（人多故弄玄虚），奇物滋起（怪物就会滋起）；法令滋彰（频频颁布法令），盗贼多有（盗贼多有产生）。故圣人云（因此圣人说）：我无为而民自化（我们无为民心自然归化）；我好静而民自正（我们清静民心自然纯正）；我无事而民自富（我们无事民心自然富裕）；我无欲而民自朴（我们无欲民心自然厚朴）。</p> 第五十八章其政闷闷（执政者的政策宽厚），其民醇醇（人民自然富贵和睦）；其政察察（执政者的政策苛刻），其民缺缺（人民自然缺其所缺）。祸兮福所倚（灾祸中倚藏着福祉）；福兮祸所伏（福祉中伏藏着灾祸）。孰知其极（谁能彻底明白端倪）？其无正（没有标准参考）。正复为奇（正直为何变的诡诈）？善复为恶（善良为何变的恶毒）？人之迷（人们为此感到迷惑），其日固久（时间已经久远了）。是以圣人（所以圣人），方而不割（方正而不生硬），廉而不刿（锐利而不伤人），直而不肆（耿直而不放肆），光而不耀（光明而不炫耀）。</p> 第五十九章治人事天（治理人民要像祭天一样），莫若啬（莫过于知道什么叫珍惜）。夫惟啬（你惟有知道什么叫珍惜），是谓早复（才能早日顺从自然之道）。早复（早日顺从自然之道），谓之重积德（才能不断积累道德）。重积德（不断积累道德），则无不克（则战无不克）；无不克（战无不克），则莫知其极（则没有人知道他的能量极限）；莫知其极（没有人知道他的能量极限），可以有国（就可以把国家托付给他）；有国之母（有了治理国家的雄厚基础），可以长久（就可以长久保持安定的局面）。是谓深根固蒂（这就是那根深蒂固），长生久视之道（生机蓬勃长久不息的大道）。</p> 第六十章治大国若烹小鲜（治理大国就像烹饪鲜美的小鱼）。以道莅天下（以这个道理治理天下），其鬼不神（鬼怪就不灵验了）。非其鬼不神（不是鬼怪不显灵了），其神不伤人（而是显灵也伤害不了人）。非其神不伤人（不但鬼怪伤害不了人），圣人亦不伤人（圣人亦不去伤害人民）。夫两不相伤（双方和睦两不相伤），故德交归焉（所以德性相融归入本源）。</p> 第六十一章大国者下流（大国要象江河下游一样使百川交汇）。天下之牝（天下万物的雌性），天下之交（能赢得天下万物雄性愿与之交合），牝常以静胜牡（是因为雌性常以恬静赢得雄性的欢心），以静为下（以恬静作为征服天下雄性的德行）。故大国以下小国（所以大国以随和谦下的意识对待小国），则取小国（则必然取得小国的欢心与信赖）；小国以下大国（小国以随和谦下的意识对待大国），则取大国（则必然取得大国的欢心与信赖）。故或下以取（所以或是以随和谦下的意识赢得信赖），或下而取（或是以随和谦下的意识而换得信赖）。大国不过欲兼畜人（大国不要过分想兼并小国），小国不过欲入事人（小国不要过分想奉承大国）。夫两者各得其所欲（如果两者要想各得其所），大者宜为下（大国统治者更应该谦下）。</p> 第六十二章道者（把道作为宗教信仰者），万物之奥（认为万物之奥妙都隐藏在道中）。善人之宝（善良的人把道看作生命中至宝），不善人之所保（不善良之人也把道看作他们的保护神）。美言可以市尊（真善美的言辞可以获得许多人的尊敬），美行可以加人（真善美的行动可以吸引更多的人参加）。人之不善（人如果产生了不善的思想），何弃之有（用什么方法可以放弃邪念）？故立天子（因此就创立了一个上帝），置三公（又为上帝设置了三位助手）。虽有拱璧以先驷马（有人虽然有宝玉以及先进的马车），不如坐进此道（但他还是愿意相信这样的信仰）。古之所以贵此道者何（古人为何要创建这样的信仰呢）？不曰以求得（不是传说“有求必应” ），有罪以免邪（ “有罪也可以免除”吗）？故为天下贵（所以这种道就成了天下珍贵的信仰）。</p> 第六十三章为无为（以自然无为为有为），事无事（以平安无事为大事），味无味（以恬淡无味为佳味）。大小多少（无论大事小事还是多得少得），抱怨以德（都要用以德抱怨的积极心态）。图难于其易（欲想突破困难必须从容易处下手），为大于其细（为了成就大事必须做好细微之处）。天下难事（天下难事），必作于易（必是从容易开始）；天下大事（天下大事），必作于细（必是从细小开始）。是以圣人（因此圣人），终不为大（始终不认为在做大事），故能成其大（所以才能成就其大业）。夫轻诺必寡信（轻易承诺必然少有信誉），多易必多难（易事累积必然难事成堆）。是以圣人犹难之（因此圣人警惕难事出现），故终无难矣（所以始终不会出现困难）。</p> 第六十四章其安易持（局面安定容易维持），其未兆易谋（事变还未有迹象则容易图谋），其脆易泮（事情脆弱之时容易消解），其微易散（事物微小之初容易分散）。为之于未有（有所作为来源于空白的领域），治之于未乱（治国安邦开始于未动乱之前）。合抱之木（合抱之粗的树木），生于毫末（生成于稚嫩细弱的小苗）；九层之台（九层之高的楼台），起于累土（起建于一篮一筐的累土）；千里之行（千里之外的行程），始于足下（开始于脚踏实地的起步）。为者败之（为所欲为者必败），执者失之（执迷不悟者必失）。是以圣人（因此圣明之人），无为故无败（不去为所欲为所以不会失败），无执故无失（不会执迷不悟所以无失方向）。民之从事（有些民众做事），常于几成而败之（常常是几近成功但却功败垂成）。慎终如始（始终谨慎如一），则无败事（则无失败之事）。是以圣人（因此圣人），欲不欲（追求众人不愿意追求的境界），不贵难得之货（不会看重众人认为难得之货）；学不学（学众人不愿意学习的冷门），复众人之所过（来弥补众人所遗漏的过失）。以辅万物之自然（这样做是为了万物自然的规律），而不敢为（而自己不敢妄为）。</p> 第六十五章古之善为道者（古代善于应用大道规律的统治者），非以明民（不是用巧智诡诈的小聪明来治理民众），将以愚之（而是用敦厚朴实的大智慧来感化民众）。民之难治（民众之所以不服管教难以治理），以其智多（是因为他们看穿了巧智诡诈）。故以智治国（所以采用巧智诡诈来治国安邦），国之贼（无异于国贼）；不以智治国（不以巧智诡诈的方法来治国安邦），国之福（是国家的福音）。知此两者（知此两种治国安邦之道的统治者），亦楷式（也应该知道哪种方式是样板），常知楷式（经常感知这种楷式给民众的好处），是谓玄德（可以说是掌握了大道深奥的德性）。玄德深矣远矣（大道深奥的德性无比深远啊）！与物反矣（它可以与万物一道返朴归真），然后乃至大顺（最后的结果必然导致大顺的局面）。</p> 第六十六章江海所以能为百谷王者（江海所以能成为天下川谷的统治者），以其善下之（是它善于居下的品质决定的），故能为百谷王（所以它能够成为天下的川谷之王）。是以欲上民（因此要想成为民众的统帅者），必以言下之（必先以谦下的言辞赢得信赖）；欲先民（欲走在民众的前面），必以身后之（必须把自己的利益置之身后）。是以圣人（所以圣人），处上而民不重（处于民众之上而民并不增加负担），处前而民不害（处于民众之前而民也不感到妨害）。是以天下乐推而不厌（所以天下百姓乐于拥戴而不厌烦），以其不争（正是因为圣人不争），故天下莫能与之争（所以天下自然没有人能与他竞争）。</p> 第六十七章天下皆谓我道大（天下都传说我们得道之人神通广大），似不肖（对这种似是而非的传说不敢接受）。夫唯大（我们惟恐人们夸大事实引来不必要的麻烦），故似不肖（所以对这种传说应该持有不敢接受的态度）。若肖久矣（倘若纵容人们似是而非的传说时间久了），其细也夫（我们自然也会变为微不足道的凡夫俗子）。我有三宝持而保之（我们有三件宝抱持而得以保全自己）：一曰慈（第一件说的是慈爱），二曰俭（第二件说的是俭朴），三曰不敢为天下先（第三件说的是不敢贪天功为己有）。慈故能勇（有慈爱之心才能激发勇敢的斗志）；俭故能广（有俭朴行为才能产生广泛的美德）；不敢为天下先（有不敢贪天功为己有的思想境界），故能成器长（才能成为民众真正器重的道长）。今舍慈且勇（当今世人舍弃慈爱去空谈勇敢），舍俭且广（舍弃俭朴去空谈广德），舍后且先（舍弃求实的美德去接受沽名钓誉的赞许），死矣（这是没有出路的）。夫慈以战则胜（以慈爱之心用以征战则必胜），以守则固（守御阵地则固若金汤）。天将救之（天将救护谁），以慈卫之（必是以慈爱来卫护他）。</p> 第六十八章善为士者不武（善为领导者不须高大威武）；善战者不怒（善于作战者不会轻易动怒）；善胜敌者不与（善胜敌人者知道避敌锋芒）；善用人者为之下（善用人才者态度平和谦下）。是谓不争之德（这就是所谓的不争之美德），是谓用人之力（这就是所谓的用人之智慧），是谓配天（这就是所谓的顺配于天道），古之极（它是自古以来最高的境界）。</p> 第六十九章用兵有言（用兵打仗有这样的说法）：吾不敢为主（我不敢轻易成为主动进攻的一方），而为客（而宁可成为被迫反击的一方）。不敢进寸（不敢轻易向对方的阵地推进一寸），而退尺（而宁可将自己熟悉的阵地让出一尺）。是谓行无行（什么是所谓的行动无踪迹）：攘无臂（要进击却不显露臂膀），执无兵（要杀敌却不显露兵器），扔无敌（要制服对方却象什么敌人也没有）。祸莫大于轻敌（灾祸的到来莫过于轻视敌人），轻敌几丧吾宝（轻视敌人几乎丧失我的斗志）。故抗兵相加（所以两军对峙实力相当时），哀者胜（哀兵必胜）。</p> 第七十章吾言甚易知（我知道自己在说什么），甚易行（也知道自己在做什么）。天下莫能知（但天下人未必知道我在说什么），莫能行（更不知道我在做什么）。言有宗（我的言论是有源头的），事有君（我说的事也会得到验证的）。夫唯无知（但现在没有人能证明我的道理），是以不我知（所以才不知道我们的深浅）。知我者希（知道我们深浅的人是非常少的），则我者贵（像我们这样的得道之人则是难得可贵）。是以圣人（所以真正的圣人），被褐怀玉（外表淳朴而内心如玉）。</p> 第七十一章知不知（知道自己的盲点在那里），上（最聪明）；不知知（不知自己的盲点在那里），病（这样就有缺点）。夫唯病病（正因为把盲点当作缺点），是以不病（才可以说他没有缺点）。圣人不病（圣明之人没有缺点），以其病病（是因为他们知道自己的盲点在那里），是以不病（所以说他们没有缺点）。</p> 第七十二章民不畏威（人民不再畏惧统治者的威胁），则大威至（那么统治者的危机就会来临）。无狭其所居（不要侵害人民生存的空间），无厌其所生（不要搅乱人民正常的生活）。夫唯不厌（惟有不引发人民厌恶），是以不厌（人民自然不会厌恶你）。是以圣人（因此圣人），自知不自见（自知自明却不自以为高瞻远瞩），自爱不自贵（自爱自尊却不自以为贵人一等）。故去彼取此（所以去除自见、自贵而取自知、自爱）。</p> 第七十三章勇于敢则杀（勇于违反天道的人则会招来杀身之祸），勇于不敢则活（勇于顺从自然的人则会活的潇洒自如）。此两者（这两种不同的勇敢），或利或害（一个有利一个有害）。天之所恶（天也有它所厌恶的），孰知其故（谁也不知这是什么缘故）？是以圣人犹难之（就是圣人也很难说明到底是什么原因）。天之道（天道的规律）：不争而善胜（不与万物相争而善胜万物），不言而善应（不与万物言语而善应万物），不召而自来（不召万物而来而万物自来），单然而善谋（它宽缓自然但却善于筹划）。天网恢恢（天道就象一张巨大的网），疏而不失（虽然疏松但却不失一切）。</p> 第七十四章民不畏死（人民不怕死），奈何以死惧之（怎么还能以死亡来恐吓他们呢）？若使民常畏死（若使人民珍惜自己的生命），而为奇者（就应该对那些为非作歹者），吾得执而诛之（我把他们抓起来按照刑律杀头），孰敢（看谁还敢为非作歹）？常有司杀者杀（按正常程序应该由司杀者执行死刑），夫代司杀者杀（如果任何人都能代替司杀者执行死刑），是谓代大匠斫（这就好比外行人代替大木匠砍削木材）。夫代大匠斫者（外行人代替大木匠砍削木材），希有不伤手矣（则是很少有人不把自己的双手弄伤的）。</p> 第七十五章民之饥（民众之所以饥饿），以其上食税之多（是因为统治者的税赋过多），是以饥（因此民众才饥饿）。民之难治（民众之所以难以治理），以其上之有为（是因为统治者的妄为），是以难治（因此民众才难以治理）。民之轻死（民众之所以轻视死亡），以其上求生之厚（是因为统治者的生活奢侈），是以轻死（因此民众才轻视死亡）。夫唯无以生为者（只有不看重自己生命的人），是贤于贵生（才比过于看重自己生命的人贤明）。</p> 第七十六章人之生也柔弱（人体在生都是柔软的），其死也坚强（死了就会僵硬）。万物草木之生也柔脆（万物草木在活着时也都是柔弱脆嫩的），其死也枯槁（当它们死了就干硬枯萎）。故坚强者死之徒（因此坚强是属于死亡的一类），柔弱者生之徒（柔弱是属于活着一类）。是以兵强则不胜（所以自视兵强而发动战争则不可能赢得胜利），木强则折（树木强硬则必然因为枯萎而被折断）。强大处下（强大的总是处于下降地位），柔弱处上（柔弱的才是处于上升地位）。</p> 第七十七章天之道（自然的法则），其犹张弓欤（不像怕断弦的满弓吗）？高者抑之（顶极的自然会抑制它），下者举之（弱势的自然会保举它）；有余者损之（多余者必遭损伤），不足者补之（不足者必得补充）。天之道（自然之规律），损有余而补不足（损伤多余者而补充不足者）。人之道则不然（人为之道则不然），损不足以奉有余（损伤不足的以奉献给有余的）。孰能有余以奉天下（谁能把多余的奉献给天下）？唯有道者（只有得道的人）。是以圣人（所以圣人），为而不恃（顺应自然而不恃才傲物），功成而不处（功成名就也不愿意养尊处优），其不欲见贤（他不希望别人称自己为圣贤）</p> 第七十八章天下莫柔弱于水（天下最柔弱的莫过于水），而攻坚强者（而攻坚克强的能力），莫之能胜（却没有能胜过水的）。其无以易之（其它任何东西都不能改变水的特性）。弱之胜强（弱小战胜强大），柔之胜刚（柔和战胜刚烈），天下莫不知（这是天下都知道的道理），莫能行（但却不按这个道理去做）。是以圣人云（所以圣人有这样的观点）：受国之垢（能接受国中流言蜚语的侮辱），是谓社稷主（才是江山社稷真正的主人）；受国不祥（能承受国家天灾人祸的打击），是为天下王（才是天下百姓心中的君王）。正言若反（正确的忠告好象是逆耳之言）。</p> 第七十九章和大怨必有余怨（和解大的仇怨必有余怨难消），安可以为善（怎么可能达到善始善终）？是以圣人执左契（因此圣人虽然执有有利的契约），而不责于人（但不会因此强迫人偿还）。故有德司契（所以有德之人只会用契约来明确责任），无德司彻（无德之人却利用契约来彻底击倒对方）。天道无亲（天道对万物都一视同仁而无亲无疏），常与善人（永远与按自然规律办事的人同行）。</p> 第八十章小邦寡民（未来是“小邦寡民”式的理想社会）。使有什伯人之器而不用（人们再也不用百十人共享一个器皿），使民重死而不远徙（人民珍惜自己的生命不用舍近求远）。虽有舟舆无所乘之（家家虽然有舟有车但大多都是摆设）；虽有甲兵无所陈之（虽然能看见盔甲兵器却无陈列之处）。使民复结绳而用之（人民从结绳的启示中获得更高智慧）。甘其食（品尝着甘甜的佳肴），美其服（欣赏着美丽的服装），安其居（享受于安居的生活），乐其俗（陶醉于快乐的民俗）。邻邦相望（邻里之间相互观望），鸡犬之声相闻（鸡犬之声相互闻听），民至老死不相往来（民至老死不相往来）。</p> 第八十一章信言不美（真诚守信的言辞不一定美妙动听），美言不信（美妙动听的言辞不一定真诚守信）。善者不辩（善表自我观点的人不会急于申辩），辩者不善（急于申辩的人不善表达自我观点）。知者不博（明白大道规律的人不会自认渊博），博者不知（自认渊博的人不会明白大道规律）。圣人不积（圣人不会积累自己的财富），既以为人己愈有（尽全力帮助他人自己感觉愈有）；既以与人己愈多（尽全力给予他人自己感觉愈多）。天之道（天道规律），利而不害（有利于万物而不妨害万物）；圣人之道（圣人的准则），为而不争（为天下传道而永远无有所求）。</p> 十年Kubernetes：过去、现在和未来 2024-12-30T00:00:00+00:00 十年Kubernetes：过去、现在和未来</h1> 翻译自https://thenewstack.io/10-years-of-kubernetes-past-present-and-future/</a></p> Matt Butcher 回顾了事情的起点，Kubernetes走向成熟的历程，以及它在WebAssembly运动中的潜力。</p> 2024年6月12日上午10:00 由 Matt Butcher</a> 撰写</p> 今年，Kubernetes</a> 迎来了它的十岁生日。作为一个从社区早期就参与其中的开发者，我不禁回顾了Kubernetes的起点，如何走向成熟，以及它现在在WebAssembly</a> 运动中的潜力。</p> 由于我是Taylor Swift的粉丝，我把这些回忆分成了几个时代，以致敬我最喜欢的音乐家。</p> 时代一：Kubernetes的简易时代</h2> 最初，有 Borg</a>。我在2010年代初在Google工作了一段时间，然后离开了，加入了一个名为Deis的PaaS创业公司。我在Google的Nest部门工作（制造恒温器和烟雾报警器的部门）。与Google的其他部门不同，Nest当时使用Apache Mesos和Apache Zookeeper来协调其VM。然而，我也使用AppEngine构建了一个内部应用程序。通过此，我接触到了Google内部的LXC容器调度程序。Borg非常强大，它全球扩展，需要数百名工程师来维护。我一度想过加入Borg团队中的一个，最终选择了离开，去Deis构建一个开放源码的替代品。</p> Deis是Docker</a> 容器领域的早期进入者。团队成员参与了Docker网络架构的开发，并对CoreOS的工具进行了大量贡献。但我们正在寻找一个强大的编排系统来简化我们的PaaS调度代码。当 Google将Kubernetes开源</a>时，我非常激动。这里有所有Borg的好处，但包装更简洁。</p> 简洁，这是当时我用来形容Kubernetes的词。</p> 它是简洁</strong>的，因为与其描述一个生命周期或一组程序指令，我只需声明</strong>应该运行什么。Kubernetes接收这个声明并实现它。</p> 它是简洁的，因为不需要编写代码，我只需写几行YAML（当时确实只有几行）。然后我只需使用一个简单的CLI上传那些YAML。</p> 它是简洁的，因为只有几种Kubernetes对象。每天我都只需要用到Pods, ReplicationControllers, Services和Secrets。</p> 在Deis，我们重构了整个PaaS平台，建立了Helm并创作了《儿童图解Kubernetes指南》。在容器生态系统中，我们都在快速行动（和破坏东西）。我仍然记得Kubernetes团队宣布可以运行 1000节点集群</a> 的那一天。第一次KubeCon可以容纳在一个酒店的宴会厅里。CNCF作为Kubernetes知识产权的中立管理者成立。当Brendan Burns</a>离开Google加入微软创建一个专门的Kubernetes团队时，我确信生态系统已经跨越了一个重要的门槛。</p> Kubernetes即将飞速成功。</p> 时代二：成长的痛苦和收获</h2> 虽然从某种意义上说，Kubernetes早期的稀疏和简化是有吸引力的，但它也是有局限的。要在生产环境中运行微服务，还需要其他特性。ReplicationControllers被ReplicaSets取代，ReplicaSets又促成了Deployments, DaemonSets, StatefulSets等更高层级的控制特性。ConfigMaps加入了Secrets，存储系统也得到了成长和成熟。自动缩放器，作业，RBAC等进入了Kubernetes核心。第三方资源让位给了更灵活的自定义资源描述（CRDs）。CRDs现在已经成为扩展Kubernetes资源（类）系统的标准方式。</p> 曾经简单的系统很快变得复杂起来，但这是必要的。如果Kubernetes要像曾经仅限于Borg的编排那样普及，它需要支持各种配置、用例和安全策略。</p> 不仅仅是技术上的变化，Kubernetes周围的生态系统也在变化。CNCF成长为一个全面的、广泛的基金会。从TOC到SIGs再到TAGs，以及项目的孵化、沙箱和毕业的严谨结构，CNCF增添了生态系统所需的严谨性。至于Helm，我们“离开”了Kubernetes项目（曾是一个子项目），成为最早的CNCF沙箱项目之一，这使我们拥有了自己的发布节奏、构建基础设施和治理政策。这一切都是在CNCF蓬勃发展的过程中得以实现的。容器运行时的动荡导致了开放容器计划（OCI）的创建，OCI已经发展成一个保护容器规范核心的标准组织。</p> 在当时，每一个变化都感觉是动荡的。我们都意识到，如果Kubernetes赢得当时称为“编排战争”，还有很长的路要走。Apache Mesos, CoreOS Fleet, Docker Swarm和HashiCorp Nomad都在与Kubernetes一争高下</a>。即使Mesos是当时的垄断者，Kubernetes在技术和社区增长方面都超越了它（及其他）。声明式配置的思想引起了积极的共鸣，很快Kubernetes在一家公司接一家公司中出现。</p> 时代三：稳定性与创新</h2> 每一个成功的开源项目都会遇到一个时刻，那就是功能开发的压力与稳定性的需求正面交锋。项目早期，开发者可以为了改进进行破坏性更改，用户接受甚至支持这种做法。在这些早期阶段，我们渴望改进，即便意味着烦人的迁移。</p> 但当软件对于组织的运作变得至关重要时，对破坏性更改的容忍度会减少。稳定性是一个原因，因为破坏性更改会导致代价高昂的停机。另外，当更多公司、团队和项目加入这一技术时，每次软件新版本发布时重构所有工作负载变得集体昂贵（在金钱和时间上）。</p> Kubernetes，Helm等项目开始优先考虑稳定性而非速度。虽然这引起了许多想要合并和发布其功能的工程师的抱怨，但它巩固了Kubernetes在企业中的地位。</p> 然而这种做法的一个缺点是，当添加新功能时，不能破坏现有的行为。这更为复杂。Kubernetes的代码库增大，YAML清单格式变得更加冗长。Helm开发早期，我们遇到了Kubernetes内部的一个有趣限制：任何一个Kubernetes清单的最大大小是1M。以比尔·盖茨的方式，我评论道，“谁会需要一个一兆的Helm图谱？这不就是YAML文件吗？”但随着Kubernetes YAML的复杂性增加，以及Helm的功能也变得更加复杂，我们打破了1M的限制。我们添加了图谱压缩，但几年后又再度遇到了限制。有一天在LinkedIn上，我看到一个工程师的职位标题是“Helm图谱开发者”。震惊之余，我意识到，即使我当初打造Helm时认为它是一个简洁的系统，它也已成长为一个复杂的工具，需要工程师培养特定技能。</p> 2019年，我开始担忧Kubernetes会成长为一个庞大的项目，甚至那些参与其中的人也难以理解。即使一度存在这种风险，我们似乎安全地度过了这一问题。感谢技术领导层，Kubernetes设定了新的航向。开发者们不再专注于添加一个又一个功能，而是专注于构建扩展机制。稳健的CRD模式出现了。控制平面变得更加灵活。随着企业功能如策略控制固化，它们以允许各种扩展点的方式进行简化。简而言之，Kubernetes通过允许他人选择在哪里忍受附加组件的复杂性来避免内部复杂性。</p> 这一举措拯救了Kubernetes，并为超越容器的未来奠定了基础。</p> 时代四：未来是Wasm</h2> Kubernetes的一个关键灵活点是容器运行时。Kubernetes曾经要求Docker守护进程，现在仅需与Kubernetes生命周期期望一致的调度系统。Containerd、CRI-O等低级容器工具将一度单片的容器运行时分解为功能单元。这是通往未来的门口。</p> WebAssembly ——简称Wasm（发音与“awesome”押韵）——最初是一种设计用于在网络浏览器中运行的字节码格式，伴随JavaScript一起。这一承诺是更强大的客户端编程。通过Wasm，我们可以编译旧的C库，然后从JavaScript中访问它们。我们可以将高性能特性如向量数学委托给比JavaScript更适合的语言。而这一切都在一个安全的沙盒中，甚至保护JavaScript运行时免受恶意字节码的影响。</p> 2018年，我在微软的团队一部分时间维护Helm, Brigade等CNCF项目，另一部分时间尝试解决容器生态系统中的新问题。我们非常想解决一个问题，涉及无服务器函数（如AWS Lambda）。我们清楚以下两点：</p> 现有的无服务器函数底层技术并不理想。虚拟机和容器的设计假设是来宾工作负载会运行数小时、数天或数月。启动时间不是一个巨大考量，因为启动相对不频繁。</li> 最受欢迎的无服务器函数实现（AWS Lambda、Azure Functions、CloudFlare Workers等）由大型公司运营，运行在Kubernetes外部。</li> </ul> 第二点，我们在微软经常听说，对那些标准化Kubernetes的企业来说是一个恼人的问题。如一位平台工程师对我说,“我们有一个漂亮且安全的Kubernetes集群托管我们的服务器工作负载，还有这个拼凑出来的策略控制、服务和流程混搭的怪物来支持我们的AWS Lambdas。”</p> WebAssembly几乎没有风险（也没有理由）取代容器。WebAssembly的优点，如快速启动时间、小巧的二进制文件和快速执行，非常适合无服务器工作负载，没有长时间运行的服务器过程。但这些都不能使WebAssembly显然更适合通常封装在容器中的长时间运行服务器过程。相反，事实是：目前，很少有服务器可以编译为WebAssembly而无需对代码（或WebAssembly运行时本身）进行重大更改。</p> 当涉及到无服务器函数时，WebAssembly亚毫秒冷启动、接近本机的执行速度和强壮的安全沙盒使它成为理想的计算层。</p> 如果WebAssembly不会取代</strong>容器，那么我们的设计目标应是补充</strong>容器。在Kubernetes内部运行WebAssembly应涉及与现有Kubernetes功能的最深入集成。这就是 SpinKube</a> 的作用。由微软、Fermyon、Liquid Reply、SUSE等公司创建的一组开源工具，SpinKube直接将WebAssembly支持插入到Kubernetes。一款WebAssembly应用可以使用秘密、配置映射、卷挂载、服务、附加容器、网状等。这是开箱即用的。不仅如此，容器和WebAssembly可以在同一个Pod中并排运行。一个应用可以拥有一个长时间运行的服务器进程在一个容器中运行，还有一堆WebAssembly附加容器以无服务器函数的形式运行。前所未有地，可以在一个操作单元中无缝混合无服务器和服务器工作负载。</p> 由于WebAssembly需要的系统资源要少得多，Kubernetes集群中的一个节点可以运行数百甚至数千个WebAssembly应用。虽然你的集群可能永远不需要那么多，但有了这些轻巧的应用，你肯定会从你的Kubernetes集群中获得更多价值，因为你集群所需的计算能力（因此集群成本）会大幅减少。</p> 这段故事令人印象深刻的是，Kubernetes本身是WebAssembly大获成功的原因。过去几年为使Kubernetes具备可扩展性、可插拔性和高度可配置性所做的努力在这里得到了回报，因为即便一个全新的运行时也可以与默认的容器运行时并肩工作！</p> 超越原本的目的</h2> 正如我之前所说，简要看一下软件教会了我们项目演变的一些深刻东西。好的软件项目会达成其原始设计初衷。伟大的项目则会超越这些初衷。TCP/IP最初仅用于美国政府沟通。HTML被设计为传输物理学论文。JavaScript用于弹出浏览器警报并与Java Applet通信。</p> 从其创建之初，Kubernetes社区就对我们共同构建的东西有明确的理解</a>：</p> Kubernetes是一个开源的Docker容器编排系统。它负责计算集群上节点的调度并主动管理工作负载以确保它们的状态与用户声明的意图匹配。通过“标签”和“Pod”的概念，它将组成应用程序的容器分组为逻辑单元以便于管理和发现。</p> 项目确实达成了那个早期目标，现在已经超越了。</p> Kubernetes曾是Docker编排器。WebAssembly曾是浏览器运行时。两者正在我们眼前超越其原始设计。每个都展示了其作为伟大技术的潜质。两者结合将带来分布式计算的新视野。</p> Matt Butcher 是Fermyon的联合创始人兼CEO，Fermyon是一个WebAssembly云公司。Matt是Helm, Brigade, CNAB, OAM, Glide和Krustlet的原始创建者之一。他撰写并合作撰写了许多书籍，包括《Learning Helm》和《Go in Practice》。他是《儿童图解Kubernetes指南》系列的共同作者。这些天，他主要从事WebAssembly项目，如Spin, Fermyon Cloud和Bartholomew。他拥有哲学博士学位，居住在科罗拉多州。</p> 链接</a></p> 链接</a></p> 如何成为首席工程师 2024-12-30T00:00:00+00:00 文章: 虚拟讨论会：如何成为首席工程师</h1> 翻译自https://www.infoq.com/articles/virtual-panel-principal-engineer/</a></p> Ben Linders, Joy Ebertz, Pablo Fredrikson, Charlotte de Jong Schouwenburg</p> Dec 11 8 分钟</p> 关键要点</h3> 转变为首席工程师角色需要结合技术专长和领导技能，既要关注个人贡献，又要关注团队动态。</li> 对于有志成为首席工程师的人来说，关键技能包括战略思维、影响他人和有效沟通，以及同理心和指导同事的能力。</li> 与管理层合作，在公司内获得更广泛的曝光机会，并通过参加会议和指导等经验抓住持续学习的机会，可以提升职业发展。</li> 不同组织对首席工程师的定义和期望可能大不相同，这强调了适应文化和领导需求的重要性。</li> 公司应该通过明确预期角色、促进自主性和鼓励重视成长和影响力的文化，来支持首席工程师。</li> </ul> 介绍</h2> 作为一名软件工程师或个人贡献者，你职业生涯的下一步可以是成为一名首席工程师。在公司成为首席工程师的路径可能感觉不明确，从而抑制个人工程师的职业发展。然而，这也为工程师提供了发明和塑造首席工程师角色的机会。</p> 在本次小组面试中，我们将讨论成为首席工程师的旅程，涉及在这一战略角色中脱颖而出所需的技术和领导技能。我们还将探讨如何推动职业发展。</p> 小组成员：</h3> Joy Ebertz - 首席工程师 @Harness</li> Pablo Fredrikson - 首席SRE @Bitso</li> Charlotte de Jong Schouwenburg - @Bravely联合创始人，商业心理学家，执行教练，培训师</li> </ul> Q1</h2> InfoQ: 作为首席工程师是什么感觉？首席工程师在你们公司是怎样的角色？</strong></p> Joy Ebertz</strong>: 我的首席工程师角色每天、每月甚至每年都在剧烈变化。这是公司需求、我的技能以及我想做的事情之间的匹配游戏。最后这一点比初听起来更为微妙。这不仅仅是我感兴趣的事情，还可能是我目前做一些技术工作是有意义的，这样当我以后想推动某个特定的技术计划时，我将会拥有一定的公信力。</p> 另一方面，尽管我确实与我的经理一起探讨我应该做什么，有时他也会告诉我需要转换方向，但更多情况下，我的工作是自我导向和自我激励的。</p> 在这个角色中取得成功需要了解自己最有效的方式。例如，我发现当我与其他至少一个人一起工作时最有效 - 这样不仅能让我负起责任（即使他们并不主动做任何事），还能与我讨论事情（即使他们不提供任何建议）。</p> 举一些更具体的例子，我花了几个月时间调查授权框架、工具和供应商，并提出建议、计划和估算。我也曾花上好几个月的时间推动某个特定项目并与其他工程师一起编码。所以有时候我的工作是大量的研究和写作，有时候是大量的会议、演示和说服他人，有时候则是大量的编码。这真的取决于公司的需求、我的技能以及我在那一刻想做的事情。</p> 帕布罗·弗雷德里克森</strong>：作为一名首席工程师意味着要承担大量的责任（和乐趣！）。首席工程师可能有一系列的职责，通常从带领一支工程师团队编写高质量的代码开始。他们的技术专长对于引导团队达到最高生产力至关重要。除此之外，他们还专注于识别对公司有重大影响的项目。首席工程师通常是第一个发现工程流程中低效或改进领域的人，解决这些问题是他们的责任。通过这样做，他们不仅提高了团队的生产力，还提升了公司整体的价值和技术标准。</p> Charlotte de Jong Schouwenburg</strong>：我们与各种公司中的首席工程师合作——从初创公司、成长中的公司到像微软这样的企业。根据公司的文化、成长路径和领导需求，首席工程师的角色定义、需求和任务会有所不同。</p> Q2</h2> InfoQ：软件工程师应该培养哪些技能才能成为首席工程师？</strong></p> Joy Ebertz</strong>: 你走得越高，通常越需要平衡技术技能和领导技能。（请注意，我故意避开了“软技能”这个词，因为我不想暗示这些技能不重要。）然而，对于那些试图晋升的人来说，很少会在技术技能上有困难，所以我将在这里更多地关注人际和领导技能。我要讨论的第一个技能是了解大局并做出权衡。在这里，我指的是时间和精力的权衡。你在技术领域工作得越久，就会自然地注意到更多需要改进的地方。</p> 并不是所有的事情都值得花费大量时间，有些事在你是一家大公司的时候值得花时间，但如果你是一家只有十个人的初创公司，那就不值得。当你的职位越高，你需要将思维方式从寻找可以改进的地方转变为识别什么时候已经足够好了。知道什么时候放手和什么时候放下是非常重要的。你可以以平庸的方式做很多事情，或者专注于几件最重要的事情并真正做好它们。</p> 下一个技能是人们经常谈论的——影响力。你常常需要让别人支持你，以完成你想做的事情。影响力不仅仅是提出好的论点。它涉及到理解人们的动机，以及公司的文化、团队和个人。如果人们说不，是因为他们认为你的提议是个坏主意，还是因为他们太忙没有时间来处理？如果是后者，有没有什么办法可以解决他们的问题或改善他们的情况？</p> 最后一个我想提到的技能是沟通。你可以将其视为影响力的一个子技能，但它足够重要，值得单独提及。在正式和非正式场合中，与大群体和小团体进行书面和口头沟通的提升，可以在很大程度上帮助你推广自己和你的想法。</p> Pablo Fredrikson</strong>：同理心是软件工程师应当培养的技能，以便成为首席工程师。成为一个好人是至关重要的。虽然技术技能很重要，但同理心和积极的态度更为重要。</p> 首席工程师应当能够识别各个流程中的问题并提出解决方案。他们还应愿意在需要时指导和带领其他工程师。</p> Charlotte de Jong Schouwenburg</strong>: 首席工程师将把他们的职责从内容专业知识扩展到领导、激励和鼓舞团队成员，帮助他们尽最大努力完成工作。这需要一套与内容专业知识互补的技能。</p> 相关的领导技能有很多（这个列表并不详尽，并会受到公司的文化、需求和团队成熟度的影响）：</p> 关注加强信任、自主性、目标、心理安全感、所有权</li> 激励、鼓舞和为团队提供愿景</li> 提供结构（有助于心理安全）</li> 鼓励成长型思维</li> 提供和促进持续反馈</li> 通过冲突指导团队动态转向连接</li> 突出团队在公司整体中的贡献和地位，反复强调与更大公司目标的联系（有助于产生目标感）</li> 熟练掌握情感调节</li> 学会向上管理</li> 处理困难对话的能力：坏消息、冲突管理、反馈对话、设定边界</li> 言行一致：定义你希望团队成员具体表现出的行为，并确保你自己也定期和明确地展示这种行为</li> 向上管理：说服领导层追求某个倡议的附加值，即使这需要额外的资源/成本</li> </ul> Q3</h2> InfoQ：软件工程师如何培养这些技能？</strong></p> Joy Ebertz</strong>：对于其中一些技能，例如沟通，当机会出现时，要勇于接受，即使这些机会让你感到害怕。</p> 例如，我写得越多，讲得越多，我就越感到自如，并且越发发现自己有很多话要说。我发现一些书籍对其他技能有帮助，但与人交流也对我很有帮助。找到一个同龄人或更资深的导师，和他们谈论其中一些事情，可以很好地验证你的直觉，并帮助你注意到一些你可能本不会注意到的事情。同样，与比你资深的人一起工作，特别是在需要处理复杂情况的项目上，可以很好地洞察他人如何应对这些问题。</p> Pablo Fredrikson</strong>：首先积极聆听他人的意见。不要急于立即掌握每一种技术；技术专长会随着时间慢慢积累。</p> Charlotte de Jong Schouwenburg</strong>：</p> 软件工程师可以通过以下方式培养技能：</p> 通过榜样学习 - 观察、反思和整合你看到的鼓舞人心且有效的领导者应用的技能（这些可以是来自其他专业领域的领导者，因为这些技能在各个领域内都适用）。</li> 寻找培训，尤其是那些有行动学习环节的研讨会，这样可以让你在真实、相关的场景中运用新技能。</li> 尽可能多地实践——领导力体现在日常行为和沟通技能中。尝试引入、重复并在现实生活中完善尽可能多的技能（例如，反馈）。</li> </ul> Q4</h2> InfoQ：软件工程师可以做什么来提高作为（技术）领导者的效率并增加他们的影响力？</strong></p> Joy Ebertz</strong>：除了培养你的技能之外，我还要提到三件事。首先是利用你的经理——将他们视为你的合作伙伴。这将有助于你负责领域的最佳结果，并确保他们知道你的目标和你特别希望发展的技能，以便他们帮助你找到机会。</p> 其次，要留意获得更广泛曝光机会的方式——让别人看到你自己，同时更好地了解公司不同团队、部门和学科中正在发生的事情。如果你没有接触到这些高层面的视野，很难形成整体的图景并做出权衡。</p> 利用你的经理来让你参与更高层的会议，或者如果他们不能带你参与，也可以为你进行总结。最后，抓住机会结识全公司各个领域的人。如果你能做一点小事来帮助他们（而不影响我之前提到的优先排序），那就去做。在各个领域积累社会资本并提高你对其他团队如何看待公司、他们的工作等的理解是非常宝贵的。</p> Pablo Fredrikson</strong>：参加会议是一个很好的起点！会议让你可以从他人的经验中学习，包括他们所面临的挑战以及他们如何解决这些问题。指导他人是另一个优秀的成长方式。我经营一个YouTube频道，在那里分享我日常工作中使用的技术见解。我发现创建内容需要对我讨论的主题有深入的理解，因此在准备分享知识的过程中，我加深了自己的专业知识。分享知识无疑增强了我的技术技能。</p> Charlotte de Jong Schouwenburg</strong>：要变得更有效，他们可以做我之前提到的三件事：通过他人学习、寻求培训和通过榜样实践。</p> 练习成就完美，并且透明地表现出你在不断学习、发展和努力的过程中作为一个完美的榜样行为，你希望从你的团队成员那里看到同样的行为。</p> Q5</h2> InfoQ：公司可以做些什么来建立和塑造首席工程师角色？</strong></p> Joy Ebertz</strong>：公司建立和塑造首席工程师角色的最佳方式是清楚地描述他们希望从这个角色中获得的东西，同时允许任何被聘用的人进一步塑造或重塑这个角色。如果他们聘用的至少前几位首席工程师对组织需求和解决问题有良好的理解，这种方式特别有效。</p> 我见过的两种失败模式是一种是过于限制性的公司，不给予工程师自由或杠杆去做他们认为最重要和有影响力的事情，另一种是过于松散的公司，不太确定他们想从资深工程师那里得到什么，因此不给他们足够的方向来入手。</p> Pablo Fredrikson</strong>：找到有潜力的人——那些关心学习并渴望指导他人的人。这些人在几年后很可能会成为公司的领导者。留住他们，并提供成长和产生影响的机会！</p> Charlotte de Jong Schouwenburg</strong>：</p> 公司可以做的事情包括：</p> 支持自主性：设定清晰的职业路径</li> 通过概述期望的品质、行动和成长路径管理期望</li> 展示影响范围</li> 定义他们可以和不能做的事情的边界</li> 清楚公司文化；言行一致地表现出对员工的期望</li> </ul> 结论</h2> 首席工程师从事各种任务，如领导技术团队、影响决策和推动改进。他们的工作会根据公司的需求和个人目标进行调整。</p> 在这个角色中取得成功需要平衡技术专长和领导能力。重要技能包括大局思维和做出权衡、影响他人、理解团队动态、沟通以及人际技能，如指导和激励团队。</p> 工程师可以通过指导、培训、观察和实践来构建这些技能。积极聆听、抓住领导力机会并接触更广泛的公司职能是推荐的做法。</p> 公司应该明确期望，提供自主性，并允许首席工程师灵活塑造他们的角色。提供成长机会并培养学习和领导文化是至关重要的。</p> 关于作者</h2> Ben Linders</strong></h4> Joy Ebertz</strong></h4> Pablo Fredrikson</strong></h4> Charlotte de Jong Schouwenburg</strong></h4> Learn excalidraw 2024-11-08T00:00:00+00:00 https://excalidraw.com/</p> Keyboard shortcuts</h3> Tools</strong></p> Tool</th> Press This</th></tr></thead> Hand (panning tool)</td> H</code></td></tr> Selection</td> V</code> or 1</code></td></tr> Rectangle</td> R</code> or 2</code></td></tr> Diamond</td> D</code> or 3</code></td></tr> Ellipse</td> O</code> or 4</code></td></tr> Arrow</td> A</code> or 5</code></td></tr> Line</td> L</code> or 6</code></td></tr> Draw</td> P</code> or 7</code></td></tr> Text</td> T</code> or 8</code></td></tr> Insert image</td> 9</code></td></tr> Eraser</td> E</code> or 0</code></td></tr> Frame tool</td> F</code></td></tr> Laser pointer</td> K</code></td></tr> Pick a color from the canvas</td> I</code> or Shift + S</code> or Shift + G</code></td></tr> Edit line/arrow points</td> Ctrl + Enter</code></td></tr> Edit text / add label</td> Enter</code></td></tr> Pick a color from canvas</td> Enter</code> or Shift + Enter</code></td></tr> Finish editing (text editor)</td> Esc</code> or Ctrl + Enter</code></td></tr> Curved arrow</td> A + click + click + click</code></td></tr> Curved line</td> L + click + click + click</code></td></tr> Add a new line (text editor)</td> Q</code></td></tr> Prevent arrow binding</td> Ctrl</code></td></tr> Add/ Update link for a selected shape</td> Ctrl + K</code></td></tr> </tbody></table> View</strong></p> To Do This</th> Press This</th></tr></thead> Zoom in</td> Ctrl + +</code></td></tr> Zoom out</td> Ctrl + -</code></td></tr> Reset zoom</td> Ctrl + 0</code></td></tr> Zoom to fit all elements</td> Shift + 1</code></td></tr> Zoom to selection</td> Shift + 2</code></td></tr> Move page up/down</td> PgUp</code> or PgDn</code></td></tr> Move page left/right</td> Shift + PgUp</code> or Shift + PgDn</code></td></tr> Move the page up/down</td> F</code></td></tr> Zen mode</td> Alt + Z</code></td></tr> Snap to objects</td> Alt + S</code></td></tr> Show grid</td> Ctrl + '</code></td></tr> View mode</td> Alt + R</code></td></tr> Toggle theme</td> Alt + Shift + D</code></td></tr> Stats for nerds</td> Alt + /</code></td></tr> </tbody></table> Editor</strong></p> To Do This</th> Press This</th></tr></thead> Move canvas</td> Space + drag</code> or Wheel + drag</code></td></tr> Reset the canvas</td> Ctrl + Delete</code></td></tr> Delete</td> Delete</code></td></tr> Cut</td> Ctrl + X</code></td></tr> Copy</td> Ctrl + C</code></td></tr> Paste</td> Ctrl + V</code></td></tr> Paste as plaintext</td> Ctrl + Shift + V</code></td></tr> Select all</td> Ctrl + A</code></td></tr> Deep select within the box, and prevent dragging</td> Shift + click</code></td></tr> Deep select</td> Ctrl + click</code></td></tr> Deep select within box, and prevent dragging</td> Ctrl + drag</code></td></tr> Copy to clipboard as PNG</td> Shift + Alt + C</code></td></tr> Copy styles</td> Ctrl + Alt + C</code></td></tr> Paste styles</td> Ctrl + Alt + V</code></td></tr> Send to back</td> Ctrl + Shift + [</code></td></tr> Bring to front</td> Ctrl + Shift + ]</code></td></tr> Send backward</td> Ctrl + [</code></td></tr> Bring forward</td> Ctrl + ]</code></td></tr> Align top</td> Ctrl + Shift + Up</code></td></tr> Align bottom</td> Ctrl + Shift + Down</code></td></tr> Align left</td> Ctrl + Shift + Left</code></td></tr> Align right</td> Ctrl + Shift + Right</code></td></tr> Duplicate</td> Ctrl +</code> D or Alt + drag</code></td></tr> Lock/unlock selection</td> Ctrl + Shift + L</code></td></tr> Undo</td> Ctrl + Z</code></td></tr> Redo</td> Ctrl + Y</code> or Ctrl + Shift + Z</code></td></tr> Group selection</td> Ctrl + G</code></td></tr> Ungroup selection</td> Ctrl + Shift + G</code></td></tr> Flip horizontal</td> Shift + H</code></td></tr> Flip vertical</td> Shift + V</code></td></tr> Show stroke color picker</td> S</code></td></tr> Show background color picker</td> G</code></td></tr> Decrease font size</td> Ctrl + Shift + <</code></td></tr> Increase font size</td> Ctrl + Shift + ></code></td></tr> </tbody></table> Linux Terminal Apps 2024-11-07T00:00:00+00:00 zellij</h1> 把这个放在最前面的目的，是因为这是后面所有软件的外壳。终端的分屏工具，原来我是用tmux的，目前已完全换到了zellij，同类软件还有screen等。 https://github.com/zellij-org/zellij</p> aerc</h1> 一个简单易用的终端下的邮件客户端我分别测试了notmuch，himalaya，mutt，aerc 目前感觉aerc是最简单易用的。 https://sr.ht/~rjarry/aerc/</p> aichat</h1> 终端ai工具，可以用来翻译markdown文件，非常方便。</p> </p> https://github.com/sigoden/aichat</p> khal + vdirsyncer + todoman</h1> khal 是一个终端的日历管理工具 vdirsyncer 是一个caldav同步工具 todoman 是个基于caldav的todolist 这三个工具搭配Synology Nas</code>食用药效极佳</p> https://github.com/pimutils/khal</p> https://github.com/pimutils/vdirsyncer</p> weechat</h1> 一直在挂机的irc客户端</p> vim</h1> 这个就不评价了</p> </h1> The definitive guide to feature management. 2024-10-20T00:00:00+00:00 什么是特性管理？</h4> 特性管理是由特性标志（feature flags）驱动的一类新的软件开发工具和技术。一个特性标志</strong>是代码中的一个控制杠杆（一个_if-else_语句），它将代码部署与特性发布解耦。开发者多年来一直在使用特性标志的一些变体。但是，当涉及到享受特性标志的全部好处时，许多人只是触及了表面。</p> 在大多数组织中，特性标志的艺术仅限于少数几个团队的几个用例。这种限制部分源于大规模管理特性标志的挑战性。首先，如果你开始大量使用标志，技术债务可能会迅速累积。因此，最终只有少数开发者使用它们，从而限制了组织可以从这些标志中捕获的价值（看我们做了什么？）。传统标志的另一个缺点是它们只支持基本的真-假，或布尔值，用例。这也阻碍了组织实现特性标志的全部好处。</p> 像LaunchDarkly这样的特性管理平台</a>填补了传统特性切换的空白。它提供了一个简单的用户界面、强大的基础设施和一套功能，使你能够在大规模上使用特性标志。更重要的是，LaunchDarkly支持广泛的复杂用例——多变量特性标志、用户细分、特性委托、A/B测试和实验等——全部集成在一个平台中。你得到了所有特性标志的好处，而没有维护自己的特性标志管理系统的风险和开销。</p> 在接下来的页面中，我们将解释什么是特性管理，它适用于谁，以及为什么你应该关心。</p> 让我们首先探讨特性管理与渐进式交付（Progressive Delivery）之间的关系，这是一种新的和重要的软件开发生命周期。</p> 特性管理与渐进式交付</h4> 渐进式交付</a>是一种新的软件开发方法论，它建立在持续交付的核心原则之上。你可以将其视为CI/CD的下一个迭代，但更加强调风险降低、业务成果和控制。特性管理是渐进式交付的关键推动者。两者是交织在一起的。因此，特性管理和渐进式交付的目标几乎相同。</p> 和它的前身CI/CD一样，我们预计渐进式交付将塑造软件的构建和交付方式；并决定现代软件开发中的胜者和败者。</p> 特性管理及其四大支柱对渐进式交付至关重要。要了解更多关于渐进式交付的起源，请点击这里</a>。要更深入地了解这种方法论，请获取我们的免费渐进式交付电子书</a>。</p> 顺便说一下，特性管理已经被证明可以在DevOps研究和评估小组（DORA）在年度《DevOps现状》报告中列出的软件开发和交付的四大关键指标上推动性能改进。</p> 特性管理与四大DORA指标</h4> 特性管理使团队能够在DevOps研究和评估小组（DORA）设定的软件开发和交付的四大关键指标上提高性能：</p> 部署和发布频率：IBM使用LaunchDarkly从每周部署到生产两次增加到每天100多次。阅读完整的IBM案例研究</a>。</p> </li> 变更的前置时间：2020年的一项调查显示，在使用LaunchDarkly后，客户的变更前置时间减少了76%。查看完整的调查结果在“特性管理的ROI。”</a></p> </li> [平均恢复服务时间（MTTR](https://xn–(mttr-k86ht1z1tdltqqve4qsv7c2t6t/)）：Atlassian，Trello、Confluence和Jira等流行软件产品的制造商，使用LaunchDarkly将其MTTR小时数减少了97%。阅读完整的Atlassian案例研究</a>。</p> </li> 变更失败率：LaunchDarkly使Honeycomb能够保持0.1%的变更失败率——这一壮举使Honeycomb成为DORA的《2019年DevOps现状》报告中的精英中的精英。观看Honeycomb的证词视频</a>。</p> </li> </ol> https://images.prismic.io/launchdarkly/c5083c0d-8f3a-473b-9dcf-1cd6f6b12a3f_Screen+Shot+2020-06-27+at+2.51.26+PM.png?auto=compress,format</a></p> 来源：“加速：2019年DevOps现状。”DevOps研究与评估，第18页</em></p> https://images.prismic.io/launchdarkly/9a5acab5-840e-45c2-8127-806e758de9a6_honeycomb.png?auto=compress,format</a></p> “Honeycomb的变更中不到0.1%会灾难性失败。相比之下，行业平均水平，大约不到5%被认为是良好的表现，许多公司努力实现在10-30%的变更失败率之间。我们的部署中只有1/1000会失败——这在很大程度上是因为LaunchDarkly允许我们开启和关闭事物以确保安全。”</p> Liz Fong-Jones</p> 首席开发者倡导者</p> 特性管理的四大支柱：构建、运营、学习、授权</h4> 特性管理由四大支柱组成：构建、运营、学习、授权。许多软件团队从构建开始他们的功能管理之旅。他们可能会使用特性标志进行基于主干的开发</a>和管理发布。其他团队可能首先使用特性标志进行后端运营目的，例如在网站流量异常激增时禁用非必要的网络服务。其他团队甚至可能从学习支柱开始功能管理之路，进行实验</a>和A/B测试，以发现用户和系统行为的洞察。总的来说，我们鼓励组织从构建支柱开始使用特性标志，并随着时间的推移逐步进入其他支柱。</p> 但不管你从哪个支柱开始，你的长期目标应该是参与特性管理的所有四大支柱。利用特性标志进行所有四大支柱的用例等同于在精英级别上实践特性管理。</p> 你对特性管理的使用越先进，你将获得的好处就越多。这就像一部智能手机。如果你只使用智能手机拍照、浏览互联网和获取驾驶方向，毫无疑问，你会比使用旧翻盖手机获得更多的好处。即便如此，你实际上只触及了智能手机全部功能的一小部分。直到你开始在移动中管理你的电子邮件，听每一首歌，从飞机上更新你的银行账户，在你还在吃午餐的时候虚拟支付给朋友午餐费用等，你才意识到你口袋里的计算机有多强大。</p> 就像你的智能手机一样，随着你利用更多特性管理的功能，其ROI也会增加。</p> 特性管理不应该是永久性的试点项目。它应该跨越多个团队和用例，所有这些都包含在四大支柱中。这是最大化你在特性管理上投入的时间、金钱和资源的回报的关键。</p> 在本指南的后续页面中，我们将详细解释特性管理的四大支柱，并解释你将如何受益。</p> Build - The first pillar 2024-10-20T00:00:00+00:00 What is Build?</h2> The Build pillar addresses the use of feature flags for building and delivering new features, bug fixes, and code changes of any kind. While much of this category deals with release management, we’ve named it “Build” because of the critical role feature flags also play in pre-release activities. Such activities might include trunk-based development, testing in production, and rollout planning.</p> Traditional software development is reactive: teams push code and pray things go well. Build offers a proactive approach, wherein developers test features in production and collect user feedback before a release. This implies making feature flags an essential part of your release strategy. </p> Build thus spans release management and pre-release activities. </p> What is the goal of Build?</h2> The main goal of Build is to enable teams to ship continuously, enjoy risk-free (and thus stress-free) releases, and deliver amazing digital experiences.</p> Deploy != release</h3> The core benefit of feature flags is they allow you to separate code deployments from feature releases. As a result, developers can deploy to production whenever they want, and the business can release when it’s ready.</p> The simple yet powerful ability to decouple deploy</em> from release</em> unlocks a host of other practices—trunk-based development, testing in production, targeted rollouts, etc.—that speed up development cycles, boost productivity across multiple teams (especially in Engineering), and improve customer satisfaction.</p> Deploy</strong> when you want, release</strong> when you’re ready.</h3> When the business units (e.g., Product Management) are able to control who sees which features when, it creates a topflight customer experience. Among other things, it lets customers adapt to change at a pace that is ideal for them. </p> Trunk-based development</h3> Rather than wait for PRs to get approved and endure the painful merge conflicts that follow, developers can use feature flags to commit unfinished code to the master branch whenever they want. In this scenario, the code is in a deployable state. If the code were deployed, users would be unable to see the incomplete feature. Nor could they activate the code paths for that feature. </p> Enabling developers to keep their code in a deployable state at all times is, of course, a prerequisite for Continuous Integration and Continuous Delivery (CI/CD). Thus, by enabling trunk-based development, feature flags also enable teams to do CI/CD safely. </p> “Safe” CI/CD with feature flags</h3> Feature management, and the feature flags underpinning it, enable safe CI/CD. Feature flags act as a safety net when continuously delivering software. If a feature throws a bug in production, you can disable it instantly without having to redeploy your entire application. What’s more, feature flags let you control who can see new features. You can choose to expose features to a subset of users, all users, or no users. This control empowers teams to continuously ship features—even incomplete ones—without the fear of disaster.</p> For those who have struggled to adopt Continuous Delivery due to the risks, feature management offers a solution. Feature management allows you to move fast but with control. If you ship code to production, and a failure occurs, you can use a “kill switch” (a topic we’ll cover in Operate) to resolve the incident quickly. And if, in this case, you’ve performed a canary launch, then you will have confined the impact of that failure to a small group.</p> “Feature management enables safe CI/CD” is another way of saying that feature management enables Progressive Delivery. For Progressive Delivery embodies an approach to CI/CD that is designed for failure and virtually eliminates risk when deploying software. Thus, if you leverage feature management to engage in Progressive Delivery, it’s implied that you are engaging in CI/CD.</p> Continuous Delivery without feature flags is the continuous delivery of risk.</h3> Doing CI/CD with feature management is a win-win for software organizations and customers. Software teams remove feature backlogs, validate new features from a technical and user engagement perspective earlier in the process, and end up releasing better features. And customers are shielded from performance issues as they enjoy the higher-quality software that’s been delivered to them. </p> To learn more about the interplay of feature management, CI/CD, and Progressive Delivery, read “What Is Progressive Delivery All About?”</a>.</p> Testing in production</h4> Try as you might, you can never predict what will happen in a production environment. That is not to say you should, therefore, do away with staging environments—though some feature management adopters certainly have done that. But the fact is, staging environments slow you down. And they still often fail to prevent issues when deploying a feature into a real-world context. </p> Thus, at LaunchDarkly, we contend that the safest, fastest way to deliver software is by first testing small changes in production. To do this safely, you need feature flags.</p> Testing in production frees you from the pain and inefficiency of Waterfall. Instead of waiting several weeks or months to ship simple code changes, you can get them out immediately. </p> </p> “We use LaunchDarkly to control risky changes. Sometimes there’s changes in the product that we can’t test effectively in development or in staging. And the only way we can really effectively test this is when we really get to production.”</p> Aaron Gentleman</p> Senior Engineering Manager</p> For many organizations, the first time they test a feature in production is the same day as the marketing launch for the release containing that feature. Feature flags allow engineers to test features in production far in advance of a marketing launch. So when Product or Marketing or whoever decides to release those features to customers, Engineering feels confident that those features won’t break anything. Ben Nadel, founder at InVision and an avid LaunchDarkly customer, describes such confidence as “intoxicating.”</a></p> </p> “Our engineers can deploy features as soon as they’re done building them. And we [on the release team] can gradually release those features at a pace that matches our enterprise customers’ tolerance for change.”</p> Dave Cacciatore</p> Director of Release Management</p> In the absence of feature flags, software releases can be nerve-wracking and stressful, even scary. But with feature flags, they are safe and forgettable. A big part of this can be attributed to the ability to test in production. Using feature flags as kill switches also plays a big part in making releases safe and boring. </p> </p> “Everyone tests in production. Some of us do it on purpose.”</p> Charity Majors</p> Co-Founder and CTO</p> Targeted rollouts</h4> A targeted rollout involves releasing new functionality to a defined cohort of users rather than dumping it on all users at once. Ring deployments, a term coined by Microsoft, are an example of such a rollout. You can also have a targeted rollout in which you only expose features to a specific user group without ever making them available to your entire user base. For instance, you may need to display a specific message in your application that is only relevant to customers in Singapore. As such, using feature management, you reveal the message to Singapore users while concealing it from everyone else. This, too, is a targeted rollout.</p> Targeted rollouts are examples of “release progressions”, a core tenet of Progressive Delivery. They give you total control over who sees what, when. And feature management makes it easy to create user segments, run targeted rollouts, and clean up the feature flags associated with those rollouts afterward.</p> Canary launches</h4> You’ve likely heard the grim anecdote about the “canary in the coal mine”, so we’ll spare you the details. But essentially, a canary launch entails releasing a new feature to a small group of real users before rolling it out to a broader audience. Canary launches can be done in either a randomized or targeted fashion.</p> Teams use this technique to see if anything breaks in production and to spot potential hazards. Should a system failure occur at this stage, its blast radius will have been limited to the canary group—a far preferable outcome compared to a failure affecting your entire user base. </p> Beyond measuring a feature’s impact on application performance, teams also use canary launches to look for early signs of whether a feature is likely to succeed or fail in terms of user engagement. </p> Canary launches are a quintessential example of testing in production. They differ from internal betas (dog fooding), user testing, and QA and performance testing in that they are done on real users in a production environment. All the testing approaches just mentioned happen in a controlled staging environment. Most developers can attest, you simply cannot forecast all the weirdness that will happen in production. </p> Ultimately, canary launches dramatically reduce the cost and impact of a system failure. They are the release equivalent of playing the penny slots at a casino—it’s hard to lose ten grand when you’re only gambling with pocket change.</p> A feature management platform makes it easy to perform canary launches and resolve incidents quickly when bugs arise.</p> Ring deployments </h4> A ring deployment entails gradually releasing a feature to defined user cohorts (“rings”), with each successive ring representing a higher degree of risk and uncertainty. </p> As a simple example, you might first roll out a feature to internal developers. Certain system performance criteria must be met before you can release the feature to the next ring. Assuming such criteria have been met, you might then roll the feature out to a canary group of happy customers eager to try the latest and greatest functionality. If your application remains stable, and you see high user engagement among the canary group, then you might release the feature to a larger group of users segmented by geography (e.g., users in the United States). Perhaps in this case, you feel more confident in your infrastructure for U.S. customers than you do for, say, customers in Europe. Once everything checks out with the U.S. ring, you release the feature to the Europe ring, and so on and so forth, until eventually making the feature generally available to all users. </p> At each stage of the ring deployment, you are “limiting the blast radius” of any small system failures that occur. What’s more, you are continuously iterating on the new feature throughout the process. As a result, by the time the feature has been made generally available, it performs significantly better than it would have in a traditional big-bang deployment. You might also think of a ring deployment as a gated deployment.</p> As a core technique of Progressive Delivery, ring deployments give software teams the control they need to deliver unmatched digital experiences. They vastly reduce the cost and impact of failure. And they give teams the confidence to do CI/CD safely.</p> As with canary launches, a feature management platform also simplifies the process of performing ring deployments. </p> Percentage deployments</h5> Like targeted rollouts, percentage-based deployments are gradual. But where in the former case, the user cohorts for each stage of the rollout are well defined, in percentage-based deployments, the cohorts are chosen at random. Such deployments are useful when you cannot run a beta program or when there is little variation among the intended users. </p> You may initially release a feature to a random 10% of users, then bump that up to 25%, then 50%, and so on until releasing to all users. Some companies automate this process. If at any stage in the rollout, the number of errors or response times exceed a set threshold, then the release stops. But in cases where all goes smoothly, every customer eventually gets access to new functionality with little involvement from you.</p> Many also use ring and percentage deployments in tandem. You first deploy to a hand-picked canary group, and once the feature has passed through this first ring, you can roll it out to the rest of your user base in a random percentage format.</p> Summary: The benefits of Build</h5> In Build, teams use feature management to decouple deployments and releases, do trunk-based development, engage in safe CI/CD, and test in production. They also perform targeted rollouts, canary launches, ring deployments, and percentage rollouts.</p> Teams that engage in these practices vastly improve their software delivery performance. They deploy faster, avoid disasters, and greatly reduce the impact of application failures. What’s more, they control who sees which code changes when, thus creating a masterful user experience.</p> The net result of all this is happier, more productive software teams, happier customers, and more revenue.</p> 什么是构建（Build）？</h2> 构建支柱涉及使用特性标志来构建和交付新功能、修复漏洞以及任何类型的代码更改。虽然这个类别的大部分内容涉及发布管理，我们将其命名为“构建”，是因为特性标志在发布前的活动中也扮演着关键角色。这些活动可能包括基于主干的开发、在生产环境中测试和发布计划。</p> 传统的软件开发是被动的：团队推送代码并祈祷一切顺利。构建提供了一种主动的方法，开发者可以在发布前在生产环境中测试功能并收集用户反馈。这意味着将特性标志作为你发布策略的一个重要部分。</p> 因此，构建涵盖了发布管理和发布前的活动中。</p> 构建的目标是什么？</h2> 构建的主要目标是使团队能够持续交付，享受无风险（因此也无压力）的发布，并提供令人惊叹的数字体验。</p> 部署（Deploy）≠发布（Release）</h3> 特性标志的核心好处是它们允许你将代码部署与功能发布分开。因此，开发者可以随时部署到生产环境，而业务可以在准备好时发布。</p> 将部署与发布解耦的简单但强大的能力，解锁了一系列其他实践——基于主干的开发、在生产环境中测试、针对性的发布等——这些实践加快了开发周期，提高了多个团队（特别是在工程领域）的生产力，并提高了客户满意度。</p> 随时部署（Deploy），准备好时发布（Release）</h3> 当业务部门（例如，产品管理）能够控制谁在何时看到哪些功能时，它创造了一流的客户体验。除其他外，它允许客户以对他们来说理想的速度适应变化。</p> 基于主干的开发</h3> 开发者不必等待PR（Pull Request）被批准并忍受随之而来的痛苦合并冲突，他们可以随时使用特性标志将未完成的代码提交到主分支。在这种情况下，代码处于可部署状态。如果代码被部署，用户将无法看到不完整的功能。他们也无法激活该功能代码路径。</p> 使开发者能够始终保持代码处于可部署状态，当然是持续集成和持续交付（CI/CD）的先决条件。因此，通过实现基于主干的开发，特性标志也使团队能够安全地进行CI/CD。</p> 使用特性标志进行“安全”的CI/CD</h3> 特性管理和支撑它的特征标志，使CI/CD变得安全。特性标志在持续交付软件时充当安全网。如果一个功能在生产环境中抛出错误，你可以立即禁用它，而不必重新部署整个应用程序。更重要的是，特性标志让你可以控制谁可以看到新功能。你可以选择向一部分用户、所有用户或不向任何用户展示功能。这种控制能力使团队能够持续交付功能——即使是不完整的——而不必担心灾难。</p> 对于那些因风险而努力采用持续交付的团队来说，特性管理提供了解决方案。特性管理允许你快速行动，但有控制。如果你将代码部署到生产环境，并且发生故障，你可以使用“杀伤开关”（我们将在运营中讨论的主题）来快速解决问题。而如果，在这种情况下，你执行了金丝雀发布，那么你就将故障的影响限制在了一个小群体中。</p> “特性管理使CI/CD变得安全”是另一种说法，即特性管理使渐进式交付成为可能。渐进式交付是一种为失败而设计的CI/CD方法，几乎消除了部署软件时的风险。因此，如果你利用特性管理进行渐进式交付，这意味着你也在进行CI/CD。</p> 没有特性标志的持续交付就是持续交付风险。</h3> 使用特性管理进行CI/CD对软件组织和客户来说是双赢的。软件团队消除了功能积压，从技术和用户参与的角度更早地验证新功能，并最终发布更好的功能。客户免受性能问题的影响，因为他们享受到了交付给他们的更高质量的软件。</p> 要了解更多关于特性管理、CI/CD和渐进式交付的相互作用，请阅读“渐进式交付是怎么回事？”</a>。</p> 在生产环境中测试</h4> 无论你如何尝试，你都无法预测生产环境中会发生什么。这并不是说你因此应该放弃暂存环境——尽管一些特性管理的采用者确实这样做了。但事实是，暂存环境会拖慢你的速度。而且它们仍然经常无法防止在将功能部署到现实环境中时出现的问题。</p> 因此，在LaunchDarkly，我们认为通过首先在生产环境中测试小的更改来交付软件是最安全、最快的方法。要做到这一点，你需要特性标志。</p> 在生产环境中测试使你摆脱了瀑布模型的痛苦和低效。你不必等待几周或几个月来发布简单的代码更改，你可以立即发布它们。</p> https://images.prismic.io/launchdarkly/d5baecd6-f812-4717-be86-8820fb24d25f_atlassian.svg?auto=compress,format</a></p> “我们使用LaunchDarkly来控制风险变化。有时产品中的变化我们无法在开发或暂存环境中有效测试。而我们真正有效地测试这些变化的唯一方式就是当我们真正进入生产环境。”</p> Aaron Gentleman</p> 高级工程经理</p> 对于许多组织来说，他们在生产环境中测试功能的时间与包含该功能的营销发布日是同一天。特性标志允许工程师在营销发布之前很早就在生产环境中测试功能。因此，当产品或营销或任何人决定将这些功能发布给客户时，工程团队对这些功能不会破坏任何东西感到有信心。InVision的创始人兼热衷于LaunchDarkly的客户Ben Nadel将这种信心描述为“令人陶醉的。”</a></p> https://images.prismic.io/launchdarkly/e51df588-1264-4d4c-8055-cbad569242f5_icims.svg?auto=compress,format</a></p> “我们的工程师可以在完成构建后立即部署功能。而我们[在发布团队]可以逐渐以符合我们企业客户对变化的容忍度的速度发布这些功能。”</p> Dave Cacciatore</p> 发布管理总监</p> 如果没有特性标志，软件发布可能会令人紧张、压力大，甚至可怕。但有了特性标志，它们就是安全和容易忘记的。这在很大程度上可以归因于在生产环境中测试的能力。使用特性标志作为杀伤开关在使发布安全和乏味方面也发挥了重要作用。</p> https://images.prismic.io/launchdarkly/9a5acab5-840e-45c2-8127-806e758de9a6_honeycomb.png?auto=compress,format</a></p> “每个人都在生产环境中测试。我们中的一些人是故意这样做的。”</p> Charity Majors</p> 联合创始人兼首席技术官</p> 针对性发布</h4> 针对性发布涉及将新功能发布给一个定义好的用户群体，而不是一次性地发布给所有用户。微软创造的“环部署”一词就是这种发布的例子。你也可以进行针对性发布，只向特定用户群体展示功能，而从未向整个用户群体提供。例如，你可能需要在应用程序中显示一个只与新加坡客户相关的特定消息。因此，使用特性管理，你向新加坡用户展示该消息，而对其他人则隐藏它。这也是一个针对性发布。</p> 针对性发布是“发布进度”的例子，这是渐进式交付的核心原则。它们让你完全控制谁在何时看到什么。而特性管理使创建用户细分、运行针对性发布以及在这些发布之后清理与之相关的功能标志变得容易。</p> 金丝雀发布</h4> 你可能听说过“煤矿中的金丝雀”的可怕轶事，所以我们将省略细节。但基本上，金丝雀发布涉及在向更广泛的受众发布之前，先向一小群真实用户发布一个新功能。金丝雀发布可以以随机或针对性的方式进行。</p> 团队使用这种技术来查看生产环境中是否有任何问题，并发现潜在的危险。如果在这个阶段发生系统故障，其影响范围将被限制在金丝雀群体——这比故障影响你整个用户群体要可取得多。</p> 除了衡量功能对应用程序性能的影响外，团队还使用金丝雀发布来寻找功能在用户参与方面可能成功或失败的早期迹象。</p> 金丝雀发布是生产环境中测试的典型例子。它们与内部测试（狗食）、用户测试以及QA和性能测试的区别在于，它们是在真实用户的真实环境中进行的。上述所有测试方法都发生在受控的暂存环境中。大多数开发人员都可以证明，你根本无法预测生产环境中会发生的所有奇怪事情。</p> 最终，金丝雀发布极大地减少了系统故障的成本和影响。它们是发布等价于在赌场玩一分钱老虎机——当你只拿零钱赌博时，很难输掉十美元。</p> 特性管理平台使执行金丝雀发布和在出现错误时快速解决问题变得容易。</p> 环部署</h4> 环部署涉及逐步向定义好的用户群体（“环”）发布功能，每个后续环代表更高程度的风险和不确定性。</p> 作为一个简单的例子，你可能会首先向内部开发人员发布一个功能。在将功能发布到下一个环之前，必须满足某些系统性能标准。假设这些标准已经满足，你可能会然后将功能发布给一群乐于尝试最新功能的快乐的客户的金丝雀群体。如果你的应用程序保持稳定，并且在金丝雀群体中看到高用户参与度，那么你可能将功能发布给一个按地理位置划分的更大的用户群体（例如，美国的用户）。或许在这种情况下，你对美国客户的基础设施比对欧洲客户更有信心。一旦美国环的一切都检查完毕，你将功能发布给欧洲环，以此类推，直到最终使功能对所有用户普遍可用。</p> 在环部署的每个阶段，你都在“限制”任何小系统故障的影响范围。更重要的是，在整个过程中，你都在不断地迭代新功能。因此，当功能最终普遍可用时，它的性能比传统的一次性大规模部署要好得多。你也可以将环部署视为门控部署。</p> 作为渐进式交付的核心技术，环部署为软件团队提供了他们需要的控制，以提供无与伦比的数字体验。它们极大地减少了失败的成本和影响。它们还给予了团队安全进行CI/CD的信心。</p> 像金丝雀发布一样，特性管理平台也简化了执行环部署的过程。</p> 百分比部署</h5> 与针对性发布类似，基于百分比的部署是逐步进行的。但在前一种情况下，每个阶段的用户群体是明确定义的，而在基于百分比的部署中，群体是随机选择的。当你无法运行beta程序或预期用户之间变化很小的时候，这种部署是有用的。</p> 你可能会最初向随机的10%的用户发布一个功能，然后将其提高到25%，然后是50%，依此类推，直到向所有用户发布。一些公司自动化了这个过程。如果在发布过程中的任何阶段，错误数量或响应时间超过了设定的阈值，那么发布就会停止。但在一切顺利的情况下，每个客户最终都会在你需要很少参与的情况下获得新功能。</p> 许多人还同时使用环部署和百分比部署。你首先部署到一个精心挑选的金丝雀群体，一旦功能通过了这个第一环，你就可以以随机百分比的形式将其发布给你的其余用户群体。</p> 总结：构建的好处</h4> 在构建中，团队使用特性管理来解耦部署和发布，进行基于主干的开发，参与安全的CI/CD，并在生产环境中测试。他们还执行针对性发布、金丝雀发布、环部署和百分比部署。</p> 参与这些实践的团队极大地提高了他们的软件交付性能。他们部署得更快，避免了灾难，并大大减少了应用程序故障的影响。更重要的是，他们控制了谁在何时看到哪些代码更改，从而创造了卓越的用户体验。</p> 所有这些的最终结果是更快乐的、更有生产力的软件团队，更快乐的客户，以及更多的收入。</p> Operate - The second pillar 2024-10-20T00:00:00+00:00 What is Operate?</h2> Operate, the second of the Four Pillars of Feature Management, encompasses feature flag use cases that improve the operational health of your application. It entails making feature flags a mission-critical piece of your operations. As deployment speeds and infrastructural complexity go up, so does the need for operational safeguards. Feature management is that safeguard.</p> Teams that use feature flags via a feature management platform reduce risk and ensure customers remain satisfied with their service. They dramatically cut down on serious incidents. For example, as previously cited, Honeycomb has a “change fail rate” of just 0.1%</a>, a feat shared only by the world’s most elite software teams. And the company cites its use of LaunchDarkly as a big reason for its exceedingly low failure rate.</p> But even when teams that rely on feature management do face incidents, they recover much faster than they would otherwise. For example, you may recall that Atlassian improved its mean time to restore</a> service (MTTR) hours by 97%</a> after using LaunchDarkly.</p> In Operate, teams are better equipped to meet their service level objectives (SLOs) and deliver the 100% uptime customers expect. The primary use cases of the Operate pillar include:</p> Kill switches and circuit breakers</li> Dynamic configurations</li> Service metrics (reactive monitoring)</li> Safe migrations</li> </ul> For all you DevOps engineers, site reliability engineers (SREs), software architects, and other ops professionals who feel left out of the feature flag discussion, this pillar is for you.</p> What is the goal of Operate?</h2> The main goal of Operate is to improve the operational health of your application and infrastructure through feature flags. Operate helps software teams maintain high system stability, reliability, and availability, thus giving developers the confidence to ship code faster.</p> Kill switches and circuit breakers</h3> Feature flags can be used as kill switches and circuit breakers. Both allow you to disable broken parts of your application instantly. Where they differ is in the duration they stay in your code. A kill switch is generally considered a temporary or short-term feature flag. It’s something you use in, say, a product launch. A circuit breaker, on the other hand, is a more permanent, long-term flag.</p> Example of a kill switch</h4> Let’s say you release a compute-heavy feature, and it causes latency issues. If you’ve attached a kill switch to this feature, then you can shut it off as soon as you detect the problem. One person toggles a feature flag—that’s it. Compare that to the pain of several people across multiple teams scrambling to change config files, restart the app for all users, perform hotfixes, do cumbersome rollbacks, and so on and so forth.</p> Kill switches give teams the confidence to release more frequently. For they know that if something goes wrong, they can click a button, and the problem is solved.</p> Once you’ve released a feature to all the intended users and are confident in its performance, we suggest removing the kill switch for that feature. Otherwise, technical debt will start accruing.</p> Kill switches give teams the confidence to release more frequently. If something goes wrong, they can click a button, and the problem is solved.</p> Example of a circuit breaker</h4> You insert feature flags as circuit breakers, or control points, in areas of your code where you suspect an error might occur. The incident you’re predicting might not happen today, it might not happen tomorrow, it might not happen ever. But if it does, it could set off a series of bad outcomes.</p> For example, microservices architectures often rely on various third-party services. If one of these services goes down, it can wreak havoc on your system and, consequently, your user experience. But if you attach circuit breakers (feature flags) to each third-party service, you can quickly disable a service that has suffered an outage. As such, you take what could have been a catastrophe and reduce it to a modest bump in the road.</p> Kill switches and circuit breakers give you more control over your application. They play a big part in enabling teams to move fast safely. What’s more, they span all of the Four Pillars of Feature Management and are present in all the other use cases of Operate.</p> For example, when we talk about using kill switches and circuit breakers, we’re describing dynamic configurations</em>.</p> Dynamic configurations</h3> Feature flags allow you to change configurations on the fly. This means you can change the behavior of your application without having to deploy new code, thus avoiding an application restart. If you’ve placed feature flags strategically throughout your code, then you can control your features in real-time. Dynamic configurations come in handy for things like API rate limiting, load shedding, and adjusting log levels.</p> Feature flags allow you to change the behavior of your application in real-time without having to deploy new code.</p> API rate limiting when your APIs are getting slammed</h4> Typically, when your API is getting throttled, say, from a DDoS attack, to block the offending domain, you have to change a configuration and then redeploy your application. Meanwhile, the bad actor continues slamming your API and disrupting your service.</p> But if you assign a multivariate feature flag</a> to your rate limiting rules, you can adjust your rate limit during an attack instantly and automatically. Once a domain hits your API enough times, it will trigger your circuit breakers to deny access to the bad actor. Again, in this way, feature management enables you to maintain system availability for all customers.</p> You can also use dynamic configurations for more pleasant rate-limiting purposes.</p> API rate limiting based on customer tier</h4> You can also use multivariate flags and targeting rules</a> to serve up different rate limits to different customer tiers. For example, you may offer 600 requests/minute to premium customers, 60 to standard ones, and five to free-version users. Any time someone signs up for, say, a premium subscription, the relevant feature flag will automatically set the appropriate rate limit. In this case, feature flags significantly improve your operational efficiency. We know this to be true because this is precisely how we manage our API rate limits in LaunchDarkly.</p> Also worthy of note, this particular rate limiting example fits into the Empower Pillar, in that it employs feature flags for entitlements</a>. </p> Adjust logging levels on the fly</h4> You can also use long-term operational flags to dynamically configure the mode of your server logs. For example, if your observability tool shows a spike in errors, the multivariate flag you’ve created will change the logging level from WARNING to DEBUG automatically and in real-time. This helps you find and resolve the source of the problem faster. And it also enables you to better regulate your server logs. After all, you don’t want your app generating verbose logs any longer than it has to.</p> Everything we’re describing in the Operate Pillar is much easier to do with a centralized feature management platform</a> like LaunchDarkly. For example, LaunchDarkly integrates with several observability and application performance monitoring (APM) solutions</a> such as AppDynamics, Datadog, Dynatrace, Honeycomb, New Relic, and SignalFX. These integrations help you measure how each feature affects key service metrics such as response times and error rates.</p> Service metrics (reactive monitoring)</h3> When you pair a feature management platform with your observability and APM tools, it allows you to detect incidents faster and react to them in real-time.</p> Find the cause of an incident with feature flags</h4> Imagine you’re seeing a surge in error rates. This metric event will trigger LaunchDarkly to send feature flag event data to your observability and monitoring tools. Depending on the tool you’re using, you’ll see those events displayed alongside performance graphs. This, in turn, helps you quickly pinpoint which recent feature rollout, if any, impaired your service. In this way, feature management helps you rapidly determine the root cause of an incident.</p> This is half of the reason why LaunchDarkly customers are able to consistently lower their MTTR. The other reason is, once they find the source of the problem, they can fix it immediately with a kill switch.</p> Pairing a feature management platform with your observability and APM tools allows you to detect incidents faster and react to them in real-time.</p> Consider another example.</p> Load shedding</h4> You can also use feature flags for things like “load shedding”. Imagine the response times on your website have exceeded a certain threshold. Perhaps an unusual number of users have visited your site. Let’s further assume that you’ve integrated your observability and monitoring tools with LaunchDarkly. Finally, let’s say you’ve created a long-term feature flag that instantly disables non-essential services when toggled off.</p> The moment the metric event occurs, LaunchDarkly will be alerted to the issue and automatically put your website in a degraded or reduced service mode. While this is not ideal, it does allow you to avert the disaster of your website crashing. You keep the service running while you debug and troubleshoot. You can enable these automatic feature flag changes via Flag Triggers</a> in LaunchDarkly.</p> Ultimately, tracking key service metrics alongside feature flag events improves the overall stability, reliability, and availability of your service.</p> Safe migrations</h4> Feature management—and the feature flags that fuel it—also enables ops teams to perform safer infrastructure migrations.</p> Microservices migration</h4> When adopting a microservices architecture, many unforeseen issues can arise. But if you employ kill switches at each stage of the migration, you can turn off a defective service the moment it starts acting up. This alone removes a good deal of risk in a systems migration. And it reduces the odds of you defaulting on your SLOs.</p> Database migration</h4> When moving to a new database, you can use feature flags to perform a gradual rollout of the new system. For example, at the start of the migration, you can route 100% of ‘read’ and ‘write’ events to the old database, while duplicating 10% of the write events and then pushing them to the new database. As you monitor performance and see that your system has remained stable, you can then move to the next phase of the rollout, until 100% of events are funneled to the new system.</p> In this case, you would have performed a targeted percentage deployment. But instead of gradually rolling out new functionality to customers, you’re routing data to a database. And if your application performance suffers during any part of the migration, you can halt the rollout with a kill switch.</p> Such an approach is safe and controlled. In fact, we followed this very process when switching databases at LaunchDarkly</a>.</p> Cloud migration</h4> Migrating your infrastructure from an on-premises data center to a cloud infrastructure as a service (IaaS) platform is a stressful undertaking. But feature flags bring ease, safety, and predictability to the project. For example, TrueCar migrated 500 websites to Amazon Web Services (AWS) Cloud with the help of LaunchDarkly.</p> As with the database example, TrueCar used feature flags and targeting rules to control the flow of web traffic between its legacy and cloud systems. The team would gradually increase the flow of traffic to the cloud when it became clear that it was safe to do so. They also used LaunchDarkly to route web traffic by request type. For example, web searches for “new cars” might have been associated with a cloud database, while searches for “used cars” were tied to the legacy system.</p> Feature flags simplified these complex routing rules. Moreover, LaunchDarkly’s simple and clean user interface made it easy to manage the vast sprawl of web traffic flows. In the end, TrueCar completed its cloud migration with zero downtime due to infrastructure problems.</p> </p> “Business users and application software engineers used LaunchDarkly’s A/B testing framework to manage traffic flows across the whole infrastructure. For that and many other reasons, TrueCar’s AWS migration was the smoothest, most uneventful of any I’ve ever managed.”</p> Regis Wilson</p> SRE</p> Regis Wilson details his experience using LaunchDarkly for the cloud migration in a blog post he wrote</a>. You can also read the full TrueCar case study</a>. Lastly, you can learn best practices for infrastructure migrations in our LaunchDarkly Guides</a>.</p> Feature management equips you with far more control over infrastructure changes than you would have otherwise. And it virtually wipes out risk in the process.</p> Summary: The benefits of Operate</h4> When software teams engage in the core practices of the Operate pillar of feature management, they purge their operations of risk. This is especially true of those who use LaunchDarkly in conjunction with their monitoring and observability stack. Such teams achieve greater system stability, even as developers ship more frequently. In fact, the safeguards of feature management enable this increase in speed.</p> In Operate, teams experience fewer system failures; and when failures do occur, they recover faster—often in minutes, if not seconds. Lastly, adherents of Operate preserve customer loyalty and trust. It’s hard to put a price tag on that.</p> 什么是运营（Operate）？</h2> 运营，作为特性管理四大支柱中的第二大支柱，涵盖了使用特性标志来改善你的应用程序的运营健康状况的用例。它涉及将特性标志作为你运营的关键部分。随着部署速度和基础设施复杂性的提高，对运营保障的需求也在增加。特性管理就是这种保障。</p> 通过特性管理平台使用特性标志的团队降低了风险，并确保客户对他们的服务保持满意。他们大大减少了严重事件的发生。例如，正如之前引用的，Honeycomb的“变更失败率”仅为0.1%</a>，这一成就只有世界上最精英的软件团队才能共享。该公司将其极低的失败率归功于使用LaunchDarkly。</p> 但即使依赖特性管理的团队确实面临事件，他们的恢复速度也比以往快得多。例如，你可能还记得，Atlassian在使用LaunchDarkly后将其平均恢复服务时间</a>（MTTR）提高了97%</a>。</p> 在运营中，团队更有能力满足他们的服务水平目标（SLOs），并提供客户期望的100%正常运行时间。运营支柱的主要用例包括：</p> 杀伤开关和断路器</li> 动态配置</li> 服务指标（反应性监控）</li> 安全迁移</li> </ul> 对于所有DevOps工程师、网站可靠性工程师（SREs）、软件架构师和其他运维专业人员，如果你们觉得自己被排除在特性标志讨论之外，这一支柱就是为你们准备的。</p> 运营的目标是什么？</h2> 运营的主要目标是通过特性标志改善你的应用程序和基础设施的运营健康状况。运营帮助软件团队保持高系统稳定性、可靠性和可用性，从而使开发者有信心更快地发布代码。</p> 杀伤开关和断路器</h3> 特性标志可以用作杀伤开关和断路器。两者都允许你立即禁用应用程序中损坏的部分。它们的区别在于它们在代码中的持续时间。杀伤开关通常被认为是临时或短期的特性标志。这是你在产品发布时使用的东西。另一方面，断路器是一个更永久、长期的标志。</p> 杀伤开关的例子</h4> 假设你发布了一个计算密集型功能，它导致了延迟问题。如果你为这个功能附加了一个杀伤开关，那么一旦你检测到问题，就可以立即关闭它。一个人切换一个特性标志——就这样。与多个人跨多个团队争先恐后地更改配置文件、为所有用户重新启动应用程序、执行热修复、执行繁琐的回滚等痛苦相比。</p> 杀伤开关给团队带来了更频繁发布的信心。因为他们知道如果出了问题，他们可以点击一个按钮，问题就解决了。</p> 一旦你向所有预期的用户发布了一个功能，并且对其性能有信心，我们建议移除该功能的杀伤开关。否则，技术债务将开始累积。</p> 杀伤开关给团队带来了更频繁发布的信心。如果出了问题，他们可以点击一个按钮，问题就解决了。</p> 断路器的例子</h4> 你将特性标志作为断路器或控制点插入到你的代码中，你怀疑错误可能发生的地方。你预测的事件可能今天不会发生，明天可能不会发生，可能永远不会发生。但如果它确实发生了，它可能会引发一系列不良结果。</p> 例如，微服务架构通常依赖各种第三方服务。如果这些服务之一宕机，它可能会对你的系统造成严重破坏，因此影响你的用户体验。但如果你对每个第三方服务附加断路器（特性标志），你可以在服务出现故障时迅速禁用该服务。这样，你可以将可能的灾难减少到道路上的一个适度的颠簸。</p> 杀伤开关和断路器为你的应用程序提供了更多的控制权。它们在使团队能够安全快速地移动中发挥了重要作用。更重要的是，它们跨越了特性管理的所有四大支柱，并出现在运营的其他所有用例中。</p> 例如，当我们谈论使用杀伤开关和断路器时，我们正在描述动态配置</strong>。</p> 动态配置</h3> 特性标志允许你实时更改配置。这意味着你可以在不部署新代码的情况下更改应用程序的行为，从而避免应用程序重新启动。如果你在代码中策略性地放置了特性标志，那么你可以实时控制你的功能。动态配置对于API速率限制、负载卸载和调整日志级别等事情非常有用。</p> 特性标志允许你在不部署新代码的情况下实时更改应用程序的行为。</p> 当你的API受到攻击时的API速率限制</h4> 通常，当你的API受到节流时，比如说，受到DDoS攻击，为了阻止违规域名，你必须更改配置，然后重新部署你的应用程序。与此同时，不良行为者继续猛烈攻击你的API，扰乱你的服务。</p> 但如果你对速率限制规则分配了一个多变量特性标志</a>，你可以在攻击期间立即并自动调整你的速率限制。一旦域名足够多次击中你的API，它将触发你的断路器以拒绝不良行为者的访问。同样，在这种情况下，特性管理使你能够为所有客户维护系统的可用性。</p> 你还可以使用动态配置进行更愉快的速率限制目的。</p> 基于客户层级的API速率限制</h4> 你还可以使用多变量标志和目标规则</a>为不同的客户层级提供不同的速率限制。例如，你可能为高级客户提供每分钟600个请求，为标准客户提供60个，为免费版本用户提供5个。任何时候有人注册，比如说，高级订阅，相关的功能标志将自动设置适当的速率限制。在这种情况下，特性标志显著提高了你的运营效率。我们知道这是真的，因为这就是我们在LaunchDarkly中管理API速率限制的方式。</p> 同样值得注意的是，这个特定的速率限制示例符合授权支柱，因为它使用特性标志进行权限</a>。</p> 实时调整日志级别</h4> 你还可以使用长期运营标志动态配置服务器日志的模式。例如，如果你的可观察性工具显示错误数量激增，你创建的多变量标志将自动并实时地将日志级别从WARNING更改为DEBUG。这有助于你更快地找到并解决问题。它还使你能够更好地管理你的服务器日志。毕竟，你不希望你的应用程序生成冗长的日志超过必要的时间。</p> 我们在运营支柱中描述的所有内容都可以通过像LaunchDarkly这样的集中式特性管理平台</a>更容易地完成。例如，LaunchDarkly与几个[可观察性和应用程序性能监控（APM](https://xn–(apm-kg1go6a888akhfjby22ada668hkl1dc4e62n431ag86a/)）解决方案集成，如AppDynamics、Datadog、Dynatrace、Honeycomb、New Relic和SignalFX。这些集成帮助你测量每个功能对关键服务指标如响应时间和错误率的影响。</p> 服务指标（反应性监控）</h3> 当你将特性管理平台与你的可观察性和APM工具配对时，它允许你更快地检测事件并实时做出反应。</p> 使用特性标志找到事件的原因</h4> 想象你看到错误率激增。这个指标事件将触发LaunchDarkly将特性标志事件数据发送到你的可观察性和监控工具。根据你使用的工具，你将看到这些事件与性能图表一起显示。这反过来帮助你快速确定最近的哪个功能发布（如果有的话）损害了你的服务。通过这种方式，特性管理帮助你迅速确定事件的根本原因。</p> 这就是为什么LaunchDarkly客户能够持续降低他们的MTTR的一半原因。另一个原因是，一旦他们找到问题的根源，他们可以立即用杀伤开关修复它。</p> 将特性管理平台与你的可观察性和APM工具配对，可以让你更快地检测事件并实时做出反应。</p> 考虑另一个例子。</p> 负载卸载</h4> 你还可以使用特性标志进行“负载卸载”。想象你的网站响应时间超过了某个阈值。也许不寻常数量的用户访问了你的网站。让我们进一步假设你已经将你的可观察性和监控工具与LaunchDarkly集成。最后，假设你创建了一个长期特性标志，当切换关闭时立即禁用非必要的服务。</p> 当指标事件发生时，LaunchDarkly将被提醒到问题，并自动将你的网站置于降级或减少服务模式。虽然这不是理想的，但它确实允许你避免网站崩溃的灾难。你在调试和故障排除时保持服务运行。你可以通过LaunchDarkly中的Flag Triggers</a>启用这些自动特性标志更改。</p> 最终，跟踪关键服务指标与特性标志事件一起提高了你的服务的整体稳定性、可靠性和可用性。</p> 安全迁移</h4> 特性管理——以及推动它的功能标志——还使运维团队能够执行更安全的基础设施迁移。</p> 微服务迁移</h4> 在采用微服务架构时，可能会出现许多不可预见的问题。但如果在迁移的每个阶段都使用杀伤开关，你可以在有缺陷的服务开始出现问题时立即关闭它。这本身就消除了系统迁移中的大部分风险。它还减少了你违约SLOs的可能性。</p> 当迁移到一个新的数据库时，你可以使用特性标志来逐步推出新系统。例如，在迁移开始时，你可以将100%的“读取”和“写入”事件路由到旧数据库，同时复制10%的写入事件，然后将它们推送到新数据库。当你监控性能并发现你的系统保持稳定后，你可以进入推出计划的下一阶段，直到100%的事件都被引导到新系统。</p> 在这种情况下，你将执行一个有针对性的百分比部署。但你不是逐步向客户推出新功能，而是将数据路由到数据库。如果在迁移的任何部分你的应用程序性能受到影响，你可以使用杀伤开关停止推出。</p> 这种方法是安全和可控的。实际上，我们在LaunchDarkly切换数据库时</a>正是遵循了这一过程。</p> 云迁移</h4> 将基础设施从本地数据中心迁移到云基础设施即服务（IaaS）平台是一项压力重重的任务。但特性标志为项目带来了便利、安全性和可预测性。例如，TrueCar在LaunchDarkly的帮助下将500个网站迁移到了亚马逊网络服务（AWS）云。</p> 与数据库示例一样，TrueCar使用特性标志和目标规则来控制其传统系统和云系统之间的网络流量流动。当明确安全时，团队会逐渐增加流向云的流量。他们还使用LaunchDarkly按请求类型路由网络流量。例如，对“新车”的网络搜索可能与云数据库相关联，而对“二手车”的搜索则与遗留系统绑定。</p> 特性标志简化了这些复杂的路由规则。此外，LaunchDarkly简单清晰的用户界面使得管理庞大的网络流量流动变得容易。最终，TrueCar完成了其云迁移，由于基础设施问题导致的停机时间为零。</p> https://images.prismic.io/launchdarkly/a5e885d2-0641-4457-bfe1-8b9f9d879faf_truecar.svg?auto=compress,format</a></p> “商业用户和应用软件工程师使用LaunchDarkly的A/B测试框架来管理整个基础设施的流量流动。出于这个和许多其他原因，TrueCar的AWS迁移是我管理过的最顺利、最不引人注目的迁移之一。”</p> Regis Wilson</p> SRE</p> Regis Wilson在他的一篇博客文章</a>中详细介绍了他使用LaunchDarkly进行云迁移的经历。你还可以阅读完整的TrueCar案例研究</a>。最后，你可以在我们的LaunchDarkly指南</a>中学习基础设施迁移的最佳实践。</p> 特性管理为你提供了比以往更多的对基础设施变化的控制权。它几乎消除了过程中的风险。</p> 总结：运营的好处</h4> 当软件团队参与特性管理的运营支柱的核心实践时，他们消除了运营中的风险。特别是那些将LaunchDarkly与其监控和可观察性栈结合使用的团队。这样的团队实现了更大的系统稳定性，即使开发者更频繁地交付。事实上，特性管理的保障措施使这种速度的提高成为可能。</p> 在运营中，团队经历的系统故障更少；当故障确实发生时，它们的恢复速度更快——通常在几分钟内，如果不是几秒钟的话。最后，运营的拥护者保持了客户忠诚度和信任。这很难用价格来衡量。</p> Learn - The third pillar 2024-10-20T00:00:00+00:00 What is Learn?</h2> The Learn pillar of feature management focuses on enabling all teams to better understand how software changes affect users and systems. It is designed for the entire product delivery team: developers</a>, DevOps and site reliability engineers (SREs)</a>, and product managers (PMs).</p> Of all the pillars, Learn is especially concerned with helping software orgs become more data-driven. As a part of this, it provides mechanisms for engaging in hypothesis-driven development, an approach that embeds the scientific method and experimentation into the process of building software. In this way, Learn also supports the “relentless pursuit of continuous improvement,” a key principle of Continuous Delivery</a>.</p> Learn springs naturally from the Build pillar of feature management</a>. In Build, you attach feature flags to every change to control the deployment and release processes. In Learn, you assign metrics to those flags and give the right people control over toggling them. The idea is—you’re already using feature management for releases; why not collect some data and improve your product along the way?</em>.</p> Learn, or experimentation in a feature management context, can also be thought of as “holistic experimentation.”</p> What is the goal of Learn?</h2> The goal of Learn is to enable the entire product delivery team, including developers and DevOps engineers, to continuously improve their software in terms of both operational performance and user engagement. Learn accomplishes this by making it easier for teams to collect, analyze, and act upon qualitative and quantitative data.</p> Holistic experimentation vs. traditional experimentation</h4> Holistic experimentation delivers maximum value to customers while maintaining peak system performance and unifying engineers and non-engineers. This strain of experimentation, which embodies the Learn pillar, is defined in contrast to traditional notions of experimentation.</p> Traditional: One-track learning</h3> By and large, traditional experimentation connotes running A/B tests on front-end features: design elements, site navigation, content recommendations, etc. To be sure, A/B tests yield insights that often lead to richer user experiences (and more profit). But when it comes to delivering value to all customers, front-end features are only half of the story.</p> For example, imagine you’ve released a winning feature variation after running a series of A/B tests on it. And let’s assume customers are thrilled with the idea of this feature. But then you make a vexing discovery. When hurled into production, the feature seriously impairs your application response times.</p> In this case, can you claim to have delivered value to your customers? No, not really. This is just one example highlighting the limits of thinking of experimentation solely in terms of front-end A/B tests.</p> Holistic: Full-stack learning</h3> Holistic experimentation defines value according to both front-end and back-end performance. It entails running not only A/B tests on public-facing features but also multivariate tests for back-end changes.</p> In this context, product managers can easily run experiments tied to the user interface (UI) and user experience (UX). Meanwhile, their friends in Engineering can measure the impact of those front-end features on system performance and reliability. What’s more, engineers can also run their own experiments on infrastructural changes.</p> Another component of Learn (i.e., holistic experimentation) is that teams collect both quantitative and qualitative data. And the gathering of such data is not restricted to a single event before a release. On the contrary, it can be done gradually as a part of a “release progression”</a>: ring deployment, percentage rollout, targeted release, etc. As such, you have more opportunities to iterate and improve upon a feature before moving it to general availability (GA).</p> Traditional: Experimentation in a silo</h3> Another drawback of traditional experimentation is it can conflict with an organization’s normal software development workflows. The tools and processes that business stakeholders use to run experiments are often distinct from—and, at times, incompatible with—those used by developers to take action on an experiment. This disconnect poses quite a dilemma. For one thing, after a winning feature has been determined, engineers must then rebuild it in real code.</p> Product Management and Marketing rely on engineers to deploy the triumphant features of an experiment. Thus, it would seem beneficial to unite the workflows of these teams. But instead, in a traditional setting, you get friction, inefficiency, and poor customer outcomes.</p> Holistic: Experimentation as a part of the deployment process</h3> Holistic experimentation integrates with your organization’s software development and delivery workflows. Experiments and beta tests align with the deployment process for the features you’re testing. In this way, holistic experimentation supports the objectives of everyone on the product delivery team: developers, DevOps engineers, SREs, software architects, product marketing managers (PMMs), product managers, and so on. This is in stark contrast to traditional notions of experimentation, which tend to treat developers as an afterthought.</p> Such cohesion among the product delivery team yields a host of benefits. For starters, virtually anyone can run tests without needing much developer intervention. Also, the overhead of experimenting and deploying in a holistic setting is much lower than the alternative.</p> Unlike traditional experimentation, holistic experimentation (powered by feature management) aligns with your organization’s normal software development and delivery workflows.</p> The path to reaping these benefits is much clearer when you consider holistic experimentation in the context of the LaunchDarkly Feature Management Platform</a>.</p> LaunchDarkly feature management enables holistic experimentation</h4> LaunchDarkly allows teams to manage releases and run experiments in one place. When developers wrap software changes in feature flags, those changes can then be easily experimented upon using LaunchDarkly’s Experimentation Add-on</a>. And when the experiment is done, anyone can roll out the winning feature variant in real-time from within LaunchDarkly. PMs, for example, can initiate the rollout without placing an additional burden on developers.</p> Those on the engineering, data science, and growth teams can use feature flags to both manage releases and apply metrics to what they ship, thereby measuring the output of their work.</p> LaunchDarkly allows teams to manage releases and run experiments in one place. </p> We should reiterate that LaunchDarkly supports experimentation in a real-world production environment. By testing features in production, you increase the odds of them working properly when unveiled to the full user base.</p> Ultimately, holistic experimentation, particularly with LaunchDarkly, is more efficient, affordable, and empowering. Let’s consider the following areas of the Learn pillar, in which teams put holistic experimentation into practice.</p> Beta groups (qualitative data)</li> Experimentation – A/B/n tests (quantitative data)</li> Baseline metrics</li> Performance tests</li> </ol> Beta testing (qualitative data)</h4> Beta testing with feature management is far less painful than without. In a feature management setting, developers build the new incomplete feature—while attaching a feature flag to it, of course—and then empower product managers to release it to select beta users. In addition to controlling the beta test itself, PMs can also control who to include in the beta group. With PMs thus empowered, developers can spend less time administering beta tests and more time building high-value functionality. And both parties can manage all of this in the LaunchDarkly dashboard.</p> Owing to the ease of running beta tests with LaunchDarkly, teams end up conducting more tests than they would otherwise. Consequently, they gather more customer feedback earlier in the development process. Product updates are more thoroughly vetted by customers as a result. In heeding customer feedback, developers avoid wasting months building things that flop when brought to market. Instead, they devote their time to creating features and services that customers love.</p> Atlassian has used LaunchDarkly to perform beta tests in the manner we’ve described. As a result, the company saw net promoter scores (NPS), a key indicator of customer satisfaction, go up within the first year. Read the full case study: https://launchdarkly.com/case-studies/atlassian</a></p> After running beta tests in LaunchDarkly, Atlassian saw net promoter scores (NPS) go up within the first year.</p> Animoto</a>, Reciprocity</a>, and other customers also empower PMs with the ability to run their own beta tests with LaunchDarkly and have seen similar results. We, too, at LaunchDarkly run our early access program (EAP) in this exact way.</p> All in all, beta testing in Learn enables teams to continuously improve their product, so as to maximize user engagement and satisfaction.</p> Experimentation – A/B/n tests (quantitative data)</h4> In Learn, both engineers and business stakeholders can seamlessly create and run experiments, including multivariate ones. Beyond running binary A/B tests, teams can use multivariate feature flags to test several variations of a feature at once. And as soon as the winning feature has been identified, it can be rolled out to the intended users and systems. Lastly, in Learn, teams can collect and analyze data generated from experiments within LaunchDarkly’s Experimentation Add-on</a>. Or they can use LaunchDarkly’s Data Export Add-on</a> to move raw experimentation data to their analytics stack.</p> Up to this point, we’ve made much ado about how holistic experimentation measures the impact of both front-end and back-end changes. Let’s examine this in practice.</p> Use case: Search algorithm</h4> Many organizations, particularly in e-commerce, have search algorithms on their app or website that display products, services, and information based on a user’s search query. These models often fail to grasp the intent behind user searches and, as a consequence, miss the mark in the results they generate. Given this, an online retailer might want to build a new algorithm that more reliably captures users’ search intentions. But before rolling it out, they’ll want to experiment with it.</p> In this case, product managers can run beta tests and experiments to assess the performance of the new algorithm. For instance, they might measure the number of conversions across each model, the old and the new. At the same time, DevOps engineers can measure the effects of the algorithm on system performance: response times, error rates, latency, etc.</p> In the process, they may discover that, while the beta version of the algorithm is driving conversions, it is also putting undue strain on their infrastructure. After uncovering such insights, the team can tweak the algorithm and shore up infrastructural gaps. When the algorithm is eventually released, it will be optimized for its intended purpose—generating better search results—as well as system stability.</p> Baseline metrics</h5> Baseline metrics are a function of holistic experimentation. They refer to the act of assigning test metrics to a software change (feature, bug fix, architectural change, etc.) and then tracking those metrics against a baseline. Again, you can conduct these experiments as you’re rolling the change out to either users or systems. As mentioned earlier, using LaunchDarkly feature flags and experimentation in tandem allows you to seamlessly perform these hypothesis-driven rollouts.</p> Infrastructure costs are a common baseline metric upon which DevOps/SRE teams can experiment. Generally, these teams have a good sense of what they normally pay their cloud providers (Amazon Web Services (AWS), Microsoft Azure, IBM Cloud, Google Cloud Platform, etc.). And when it comes time to release new functionality or modify their architecture, the operations team can measure how those changes affect their infrastructure costs compared to the baseline. This can lead to significant cost-savings over time.</p> Performance tests</h5> As alluded to throughout, back-end performance tests are an essential part of holistic experimentation. With feature management, development and operations teams can test hypotheses tied to key service metrics such as response times, error rates, and infrastructure costs. Moreover, they can measure the impact of new functionality on those metrics.</p> Use case: Website toolbar</h4> For example, software engineers may devise a hypothesis around the effect of a new website toolbar on page load times. Let’s imagine multiple toolbar variations with slight architectural differences. In this scenario, engineers can run an experiment as a part of a canary launch, wherein the toolbars are rolled out to a select group of real users. The engineers can thus gauge how the toolbars affect load times across different browsers, network types, and other environmental conditions, all in production.</p> Once the experiment has run its course, and the ideal toolbar has been identified, engineers can then hand the reins over to product managers. And the latter can finish the rollout at a pace that works best for the business.</p> Financial services company runs experiments on back-end infrastructure</h4> In another example, Stash</a>, a New York-based financial services company, uses LaunchDarkly to run advanced experiments on back-end infrastructure. Before, the company lacked a way to run such tests. But now, engineers can measure things like the operational impact of their content personalization services. Further, they use LaunchDarkly’s Data Export Add-on to pump experimentation data to their internal analytics platform, where they aggregate all their testing data. This has given Stash a more comprehensive, granular view into customer engagement. As a result, the company has become more data-driven and elevated the quality of its product.</p> </p> “LaunchDarkly has played a big part in helping us build a culture at Stash, where we experiment with everything. Not only that, it has enabled us to release new features way faster than before. The fact that we can manage software releases and support experimentation in the same platform is remarkable.”</p> Kahne Raja</p> Engineering Manager</p> The ability to run back-end experiments with feature management adds a powerful layer to your broader analytics efforts.</p> Summary: The benefits of Learn</h5> Feature management brings harmony to experimentation and software delivery—and to the teams involved in each pursuit. It allows developers, DevOps engineers/SREs, and product managers to collect and analyze greater quantities of data on user behavior and system performance. This enables them to make data-driven enhancements to new features at each stage of a rollout. The Learn pillar thus fuels a virtuous cycle of continuous improvement among product delivery teams.</p> Those who employ holistic experimentation deliver higher-quality software that performs exceedingly well across key metrics. They see better system reliability, operational efficiency, and user engagement. Moreover, they spot bad ideas early, scrapping them before they waste too much time, money, and resources. And they invest in the good ideas, reaping the benefits that follow.</p> Practitioners of the Learn pillar of feature management, who treat experimentation holistically, provide value to customers in increasing measure. And they enjoy greater team unity.</p> 什么是学习（Learn）？</h2> 学习支柱是特性管理的核心，它专注于使所有团队更好地理解软件变更如何影响用户和系统。它旨在服务于整个产品交付团队，包括开发人员</a>、[DevOps和网站可靠性工程师（SRE](https://xn–devops(sre-915q12d471d9nav6x865i73cl22asp8h/)）以及产品经理（PM）。</p> 在所有支柱中，学习特别关注帮助软件组织变得更加数据驱动。作为其中的一部分，它提供了进行假设驱动开发（hypothesis-driven development）的机制，这种方法将科学方法和实验嵌入到构建软件的过程中。通过这种方式，学习也支持了持续交付</a>的一个关键原则——“持续改进的无情追求”。</p> 学习自然而然地源于特性管理的构建支柱</a>。在构建中，你将特性标志附加到每个更改上，以控制部署和发布过程。在学习中，你为这些标志分配指标，并将控制权交给合适的人来切换它们。理念是——你已经在使用特性管理进行发布了；为什么不在过程中收集一些数据并改进你的产品呢？</p> 学习，或者在特性管理背景下的实验，也可以被认为是“全面实验”。</p> 学习的目标是什么？</h2> 学习的目标是使整个产品交付团队，包括开发人员和DevOps工程师，能够持续改进他们的软件，无论是在运营性能还是用户参与度方面。学习通过使团队更容易收集、分析和对定性和定量数据采取行动来实现这一点。</p> 全面实验与传统实验</h4> 全面实验在保持系统性能峰值的同时，为客户提供最大价值，并统一工程师和非工程师。这种实验，体现了学习支柱，与传统的实验观念形成对比。</p> 传统：单轨学习</h3> 大体上，传统实验意味着对前端特性进行A/B测试：设计元素、网站导航、内容推荐等。可以肯定的是，A/B测试提供了洞察，这些洞察通常会导致更丰富的用户体验（和更多利润）。但当涉及到为所有客户交付价值时，前端特性只是故事的一半。</p> 例如，想象你在对它进行了一系列A/B测试后发布了一个成功的功能变体。我们假设客户对这一功能的想法感到兴奋。但然后你发现了一个令人困扰的问题。当投入到生产中时，该功能严重损害了你的应用程序响应时间。</p> 在这种情况下，你能声称为客户交付了价值吗？不，实际上没有。这只是其中一个例子，突出了将实验仅以前端A/B测试为思考范围的局限性。</p> 全面：全栈学习</h3> 全面实验根据前端和后端性能定义价值。它不仅涉及对面向公众的特性进行A/B测试，还涉及对后端更改进行多变量测试。</p> 在这种情况下，产品经理可以轻松地运行与用户界面（UI）和用户体验（UX）相关的实验。与此同时，他们在工程领域的朋友们可以衡量这些前端特性对系统性能和可靠性的影响。更重要的是，工程师也可以对基础设施变更进行自己的实验。</p> 学习（即全面实验）的另一个组成部分是，团队收集定量和定性数据。而且，这种数据的收集并不局限于发布前的单一事件。相反，它可以作为“发布进度”</a>的一部分逐步进行：环部署、百分比发布、针对性发布等。因此，你在将功能移动到普遍可用性（GA）之前有更多的机会进行迭代和改进。</p> 传统：孤立的实验</h3> 传统实验的另一个缺点是，它可能与组织的正常软件开发工作流程发生冲突。业务利益相关者用于运行实验的工具和流程通常与开发人员用于采取实验行动的工具不同——有时甚至不兼容。这种脱节造成了相当大的困境。首先，确定获胜功能后，工程师必须在真实代码中重建它。</p> 产品管理和市场营销依赖于工程师部署实验的成功功能。因此，将这些团队的工作流程统一起来似乎是有益的。但在传统环境中，你却得到了摩擦、低效率和糟糕的客户结果。</p> 全面：作为部署过程一部分的实验</h3> 全面实验与你的组织的软件开发和交付工作流程集成。实验和beta测试与你所测试的功能的部署过程一致。通过这种方式，全面实验支持产品交付团队的每个人的目标：开发人员、DevOps工程师、SRE、软件架构师、产品营销经理（PMM）、产品经理等。这与将开发人员视为事后考虑的传统实验观念形成了鲜明对比。</p> 产品交付团队之间的这种凝聚力带来了许多好处。首先，几乎任何人都可以运行测试，而不需要太多的开发人员干预。此外，在全面环境中进行实验和部署的开销远低于另一种选择。</p> 与需要大量开发人员干预的传统实验不同，全面实验（由特性管理提供支持）与你的组织的正常软件开发和交付工作流程一致。</p> 当你在LaunchDarkly特性管理平台</a>的背景下考虑全面实验时，收获这些好处的道路变得更加清晰。</p> LaunchDarkly特性管理使全面实验成为可能</h4> LaunchDarkly允许团队在一个地方管理发布和运行实验。当开发人员将软件更改包装在特性标志中时，然后可以使用LaunchDarkly的实验附加组件</a>轻松地对这些更改进行实验。当实验完成后，任何人都可以从LaunchDarkly内部实时推出获胜的功能变体。例如，产品经理可以在不增加开发人员负担的情况下启动发布。</p> 工程、数据科学和增长团队可以使用特性标志来管理发布，并对它们发布的内容应用指标，从而衡量他们工作的结果。</p> LaunchDarkly允许团队在一个地方管理发布和运行实验。</p> 我们应该再次强调，LaunchDarkly支持在现实生产环境中进行实验。通过在生产中测试功能，你增加了它们在向完整用户基础展示时正常工作的可能性。</p> 最终，全面实验，特别是与LaunchDarkly一起，更有效、更实惠、更有力量。让我们考虑以下学习支柱的领域，在这些领域中，团队将全面实验付诸实践。</p> Beta组（定性数据）</li> 实验——A/B/n测试（定量数据）</li> 基线指标</li> 性能测试</li> </ol> Beta测试（定性数据）</h4> 使用特性管理进行Beta测试比没有特性管理要少痛苦得多。在特性管理设置中，开发人员构建新的不完整的功能——当然要附加特性标志——然后授权产品经理将其发布给选定的Beta用户。除了控制Beta测试本身，产品经理还可以控制谁被包括在Beta组中。有了这样的授权，开发人员可以花更少的时间管理Beta测试，更多时间构建高价值功能。双方都可以像这样在LaunchDarkly仪表板中管理所有这些。</p> 由于使用LaunchDarkly运行Beta测试的便捷性，团队最终会进行比他们否则会进行的更多的测试。因此，他们在开发过程的早期收集了更多的客户反馈。产品更新因此得到了客户的更彻底的审查。在听取客户反馈时，开发人员避免了浪费数月时间构建在市场推出时失败的功能。相反，他们将时间投入到创建客户喜爱的功能和服务上。</p> Atlassian已经使用LaunchDarkly以我们描述的方式进行Beta测试。结果，公司在第一年内就看到了净推荐值（NPS）——客户满意度的关键指标——上升。阅读完整的案例研究：https://launchdarkly.com/case-studies/atlassian</a></p> Animoto、Reciprocity和其他客户也通过使用LaunchDarkly让产品经理有能力运行自己的Beta测试，并看到了类似的结果。我们，在LaunchDarkly也以完全相同的方式运行我们的早期访问计划（EAP）。</p> 总的来说，学习中的Beta测试使团队能够持续改进他们的产品，以最大化用户参与度和满意度。</p> 实验——A/B/n测试（定量数据）</h4> 在学习中，工程师和业务利益相关者可以无缝地创建和运行实验，包括多变量实验。除了运行二元A/B测试外，团队可以使用多变量特性标志同时测试一个功能的几种变体。一旦确定了获胜的功能，就可以将其发布给预期的用户和系统。最后，在学习中，团队可以在LaunchDarkly的实验附加组件</a>中收集和分析实验生成的数据。或者，他们可以使用LaunchDarkly的数据导出附加组件</a>将原始实验数据移动到他们的分析堆栈中。</p> 到目前为止，我们已经讨论了很多全面实验如何衡量前端和后端更改的影响。让我们在实践中检查这一点。</p> 使用案例：搜索算法</h4> 许多组织，特别是在电子商务领域，他们的应用程序或网站上都有搜索算法，这些算法根据用户的搜索查询显示产品、服务和信息。这些模型经常无法把握用户搜索背后的意图，因此，在它们生成的结果中错过了标记。鉴于此，在线零售商可能想要构建一个更可靠地捕获用户搜索意图的新算法。但在推出之前，他们想要对其进行实验。</p> 在这种情况下，产品经理可以运行Beta测试和实验来评估新算法的性能。例如，他们可能会测量每个模型的转化次数，旧的和新的。同时，DevOps工程师可以衡量算法对系统性能的影响：响应时间、错误率、延迟等。</p> 在这个过程中，他们可能会发现，虽然算法的Beta版本推动了转化，但它也对基础设施造成了不必要的压力。在发现这些洞见后，团队可以调整算法并弥补基础设施的不足。当算法最终发布时，它将针对其预期目的——生成更好的搜索结果——以及系统稳定性进行优化。</p> 基线指标</h5> 基线指标是全面实验的一个功能。它们指的是将测试指标分配给软件更改（功能、错误修复、架构更改等），然后与基线对比跟踪这些指标。再次强调，你可以在向用户或系统推出更改时进行这些实验。如前所述，结合使用LaunchDarkly特性标志和实验可以让您无缝地执行这些假设驱动的推出。</p> 基础设施成本是DevOps/SRE团队可以实验的常见基线指标。通常，这些团队对他们通常支付给云提供商（Amazon Web Services（AWS）、Microsoft Azure、IBM Cloud、Google Cloud Platform等）的费用有很好的了解。当发布新功能或修改架构时，运维团队可以衡量这些更改与基线相比如何影响他们的基础设施成本。这可以随着时间的推移带来显著的成本节省。</p> 性能测试</h5> 如前所述，后端性能测试是全面实验的重要组成部分。通过特性管理，开发和运维团队可以测试与关键服务指标相关的假设，如响应时间、错误率和基础设施成本。此外，他们可以衡量新功能对这些指标的影响。</p> 使用案例：网站工具栏</h4> 例如，软件工程师可能会围绕新网站工具栏对页面加载时间的影响提出假设。让我们想象有多个工具栏变体，它们之间有轻微的架构差异。在这种情况下，工程师可以作为金丝雀发布的部分运行实验，其中工具栏被推广到一群精选的真实用户。工程师因此可以衡量工具栏在生产环境中对不同浏览器、网络类型和其他环境条件下的加载时间的影响。</p> 一旦实验完成，并且确定了理想的工具栏，工程师就可以将控制权交给产品经理。然后，后者可以以最适合业务的速度完成发布。</p> 金融服务公司在后端基础设施上运行实验</h4> 在另一个例子中，Stash</a>，一家总部位于纽约的金融服务公司，使用LaunchDarkly在后端基础设施上运行高级实验。以前，公司缺乏运行此类测试的方法。但现在，工程师可以衡量像他们的内容个性化服务这样的操作影响。此外，他们使用LaunchDarkly的数据导出附加组件将实验数据传输到他们的内部分析平台，在那里他们汇总了所有的测试数据。这给了Stash一个更全面、更细粒度的视图来了解客户参与度。结果，公司变得更加数据驱动，并提高了其产品的质量。</p> https://images.prismic.io/launchdarkly/4ef8b46d-7e96-4bee-be0b-1bb49899e70f_stash.svg?auto=compress,format</a></p> “LaunchDarkly在帮助我们在Stash建立一种文化方面发挥了重要作用，我们尝试一切。不仅如此，它还使我们能够比以前更快地发布新功能。我们可以在同一个平台上管理软件发布并支持实验，这是非常了不起的。”</p> Kahne Raja</p> 工程经理</p> 使用特性管理运行后端实验的能力为您更广泛的分析工作增加了一个强大的层次。</p> 总结：学习的好处</h5> 特性管理为实验和软件开发交付——以及参与每项追求的团队——带来了和谐。它允许开发人员、DevOps工程师/SRE和产品经理收集和分析更多关于用户行为和系统性能的数据。这使他们能够在推出新功能的每个阶段进行数据驱动的增强。因此，学习支柱推动了产品交付团队持续改进的良性循环。</p> 那些采用全面实验的人提供了在关键指标上表现出色的更高质量的软件。他们看到了更好的系统可靠性、运营效率和用户参与度。此外，他们早早地发现了糟糕的想法，在它们浪费太多时间、金钱和资源之前放弃它们。他们投资于好的想法，收获随之而来的好处。</p> 学习支柱的特性管理实践者，将实验视为一个整体，为客户不断提供价值。他们享受着更大的团队团结。</p> Empower - The fourth pillar 2024-10-20T00:00:00+00:00 What is Empower?</h2> Empower, the fourth and final pillar of feature management, reimagines the process of giving users access to your software. It applies especially, though not exclusively to managing entitlements. In a software context, “entitlements”</a> refers to the act of enabling or disabling features, services, and products for customers. For example, when you unlock your full application for a customer who had previously been using an abbreviated trial version, you have managed an entitlement.</p> In the Empower pillar, feature flags empower customer-facing teams—Product Management, Marketing, Sales, Customer Support, etc.—to control the granting and denying of access to certain functionality.</p> Enabling those outside of Engineering to manage access to features results in:</p> Engineers spending less time on administrative work that falls outside their scope of responsibility and expertise;</li> Customer-facing teams promptly delivering software to customers, rather than waiting for engineers to sort through a backlog of request tickets; and</li> Customers getting a personalized, superior experience.</li> </ol> Empower is the pillar of feature management that deals most closely with “progressive delegation,” another core tenet of Progressive Delivery</a>. Progressive delegation refers to gradually delegating the control of a feature to the team most responsible for the outcome of that feature (e.g., a product manager ensuring that customers are satisfied with a given feature). This might look like transferring the ownership of a feature from Engineering to Product Management, then from Product Management to Marketing, and so on. Feature management enables Progressive Delivery, and the core use cases of Empower exemplify progressive delegation.</p> Empower is all about enabling customer-facing teams to play a bigger role in delivering software.</p> The procedures of Empower echo those of the Build pillar</a>. Both employ feature flags</a> and user targeting</a> to dictate who sees which features when. Moreover, in each pillar, engineers can delegate control to non-engineers over the delivery of such features—though, engineers do less delegating in Build. </p> But the two pillars differ in where they fall in the feature lifecycle. Build focuses on the stages before and during a software release. Whereas, Empower addresses the periods during and after. It entails long-term customer targeting for things like giving an enterprise customer access to a set of features built exclusively for them. That’s just one example.</p> Software orgs can use feature management</a> to empower all teams to influence software delivery in the following areas:</p> Feature entitlements</li> Customer targeting</li> Proof of concepts (POCs) and trials</li> Sunsetting features</li> </ol> What is the goal of Empower?</h2> The goal of Empower is to enable customer-facing teams to play a bigger role in delivering software. This reduces the burden on engineers, helps business stakeholders do their jobs more effectively, and creates a better, more personalized customer experience.</p> Feature entitlements</h3> Conventional approaches to managing entitlements require developer intervention. Such approaches are more involved than they need to be. Depending on the scenario, provisioning an entitlement may require an engineer to change a configuration file (forcing a restart of the app), alter a user database, perform a custom-build, and so on. In isolation, these actions are not a big deal. But when aggregated on a large scale, they exhaust considerable time and present needless risks. Any time you modify a user database, for example, you run the risk of losing sensitive data, throwing fields into disorder, and making other costly mistakes.</p> Typically, managing entitlements requires developer intervention. Feature management reduces the burden on engineers, allowing them to do what they do best: build software.</p> Besides the risks and overhead, conventional approaches to managing entitlements are marred by yet another flaw. They force engineers to turn features ‘on’ and ‘off’ for customers when, theoretically, their colleagues in the line of business units could just as easily do this work. In fact, it makes more sense for business stakeholders to control customer experiences, given how they routinely engage with those customers. Engineers’ time would be better spent doing that which customer-facing teams cannot: building software!</p> Feature flags lift the burden on Engineering and empower customer-facing teams. Here are a few examples to illustrate the point.</p> Empowering sales teams to manage entitlements</h4> One tech company, whose software enables customers to detect, manage, and protect sensitive data across their technology stack, uses feature management for entitlements. In the past, when a customer signed up, the sales team would have to submit an engineering request to add the customer’s universally unique identifier (UUID) to a config file. Only then would the new customer get access to the features they paid for. This process strained the engineers, negatively affected the sales team, and hurt the customer experience.</p> Since using LaunchDarkly, engineers can hand off the responsibility of entitlements to the sales team. As a result, salespeople now provide faster turnaround times for clients. No more Jira tickets, no more waiting—just value delivered instantly.</p> How LaunchDarkly empowers sales teams</h4> LaunchDarkly</a> empowers sales teams in the following way. Engineers create a feature flag for the bundle of features tied to a given software membership plan (e.g., a Premium plan). Through user targeting, they then create a designated user segment for this tier. If a user is in this segment, they will see the premium features.</p> Against this backdrop, anytime a customer signs up for a premium subscription, an account executive can simply go into the LaunchDarkly dashboard and add the new customer to the appropriate segment. Taking this a step further, you can also automate the process of adding users to a segment. In this case, if a customer purchases a subscription on your website, they will automatically appear in the correct segment, in turn, granting them immediate access to the right features. LaunchDarkly thus brings ease and fluidity to entitlements.</p> Let’s explore another example.</p> Automating entitlements at a large consultancy</h4> The health and wellness arm of a large consulting firm uses LaunchDarkly to dynamically control the behavior of its new health application. LaunchDarkly feature flags enable and disable functionality based on complex business logic and in-app triggers. For instance, the company unlocks specific features only after a user has accepted the terms and conditions. The same goes for when users upgrade their accounts. Such automation increases the company’s agility, thus allowing developers to spend time improving the product versus doling out features. All of this drives engineer productivity and enhances the customer experience.</p> Customer targeting</h3> Customer targeting is another entitlements use case. The scope of this type of targeting is broader than with discrete user targeting. It entails delivering functionality to specific organizations, industries, countries, and other large entities, each containing scores of individual users.</p> Here’s an example.</p> White labeling</h4> It has become the norm for banks to provide a mobile banking app as a part of their service. In some cases, particularly among small and mid-size banks, the banks will purchase the core software for their app from a third-party provider and cloak it in their branding (a practice known as “white labeling”).</p> These third-party providers have several banks in their client portfolio, all of whom want different things. Without feature flags, the providers may create separate feature branches to deliver unique versions of their software, effectively creating custom-builds for each bank. Such an approach is hard to sustain. </p> For starters, each general change you make to one branch must be replicated across the other branches to avoid getting out of sync. The more changes you make, the more unwieldy your code becomes. Ultimately, doing customer targeting via feature branching is time-consuming, error-prone, and expensive.</p> But with feature management, software providers can deliver custom experiences to each banking client using a single master branch (trunk). And they can control who sees what with feature flags. They can build and deliver unique experiences to every customer in one codebase. Such an approach is efficient, safe, and controlled.</p> With feature management, software providers can deliver custom experiences to each customer.</p> Targeting by geographic location</h4> Many software companies serve international customers. And they must adapt their software to the laws and regulations of each country. Features that are embraced in one country may be outlawed in another. Again, one way to deliver specific functionality by country is to create separate instances of your application via a tangled mess of feature branches. We’ve already discussed the drawbacks of this approach.</p> But with LaunchDarkly, you can leverage feature flags and customer targeting to dispense the right features to the right customers by country—again, all within a single codebase. Moreover, business stakeholders can do the dispensing. As business stakeholders are more attuned to the needs (and laws) of their customers than engineers, it is wise to let them manage the entitlements for these global customers.</p> POCs and trials</h3> For many software companies, giving prospective customers temporary access to your application for trials and proof of concept evaluations (POCs) can be a thorny process. When salespeople are in the throes of a high-stakes deal, and they have to ask Engineering to extend a trial or issue temporary POC licenses, it prolongs the sales cycle. Worse, it can threaten the deal entirely. POCs often arise in sales engagements with enterprises, in which thousands or millions of dollars are on the line. The last thing you want to do is stall the deal, especially if the prospects are already test-driving competitor tools.</p> Imagine if salespeople could grant software access themselves (with proper guardrails in place, of course)? Engineers wouldn’t have to worry about fielding entitlements requests. And salespeople could more promptly deliver features to prospects, increasing the odds of outflanking competitors on the deal. If nothing else, delegating feature control means one less roadblock in sales evaluations.</p> With feature management, salespeople can</em> control software access for trials and POCs. That’s precisely what we do at LaunchDarkly.</p> LaunchDarkly’s sales team uses LaunchDarkly for POCs</h4> Our solutions engineers (SEs) on the revenue team use feature flags to issue trials without needing developer involvement. Flags allow us to quickly add LaunchDarkly seats for prospects as well as for additional groups within an existing customer organization. We want as many people to use LaunchDarkly’s product as possible so that they can see the value of it firsthand. Feature flags prevent us from getting in our own way in this regard. Moreover, they keep our engineers from having to do extra work to enable temporary and permanent features.</p> Feature flags prevent sales evaluations from stalling by granting prospects instant access to your software during a POC.</p> By opening up more seats for customers, we deliver more value during an evaluation. And we pave the way for a potentially larger business case than what was originally scoped out. More seats equal more revenue.</p> This simple process for managing entitlements also leads to happier salespeople, engineers, and customers. Through LaunchDarkly feature flags, we empower our sales team to make the best decisions for existing and future customers.</p> Sunsetting features</h4> Feature management is a powerful solution for launching new functionality. But it’s also great for retiring old features.</p> At some point, old features conflict with new ones, or they fall into disuse and become technical debt. Feature management gives teams fine-grained control over sunsetting these features. Engineers can tee up the sunsetting process with feature flags and user targeting. Then, they can delegate control of the flags to product managers, customer success reps, or someone else who has a relationship with the customers affected by the loss of features. The customer-facing team can remove the old feature at a cadence that matches each customer’s needs. This gives customers more time to wean off the feature, thus easing the pain of the transition.</p> The LaunchDarkly Feature Management Platform</a> enables you to manage the entire lifecycle of your features, including end-of-life. This creates a better customer experience when sunsetting features. It also reduces the risks of offloading old functionality by giving you more control over the process with feature flags.</p> Summary: The benefits of Empower</h4> Empower is all about giving customer-facing teams control over sections of software within their domain. Generally, business stakeholders have more insight into customers’ needs than developers. Yet, historically, they’ve lacked a way to control how features are released to these customers. At the same time, developers would gladly forfeit the perennial burden of having to enable functionality for users, assuming they could do so without added risk.</p> Feature management</a> empowers business stakeholders with the control they’ve been missing, to the benefit of all teams. When engineers build features, they can hand them off to business stakeholders and say, “Hey, we wrapped these features in a feature flag; you decide when they go live, who sees them, etc.” Everybody wins.</p> Ultimately, leveraging feature management for entitlements drives operational efficiency, greater productivity across all teams, and better customer outcomes.</p> 什么是授权（Empower）？</h2> 授权是特性管理的第四大也是最后一个支柱，它重新构想了让用户访问你的软件的过程。它特别（尽管不是唯一）适用于管理权限。在软件背景下，“权限</a>”指的是为客户启用或禁用功能、服务和产品的行为。例如，当你为之前使用过简化试用版的客户解锁完整应用程序时，你就管理了一个权限。</p> 在授权支柱中，特性标志授权面向客户的团队——产品管理、市场营销、销售、客户支持等——控制授予和拒绝对某些功能的访问。</p> 使那些在工程之外的人能够管理对功能的访问，可以带来以下结果：</p> 工程师花更少的时间在超出他们责任和专业范围的行政工作上；</li> 面向客户的团队迅速向客户交付软件，而不是等待工程师处理请求票证的积压；以及</li> 客户获得个性化、更优越的体验。</li> </ol> 授权是与“渐进式委托”这一渐进式交付</a>的核心原则最密切相关的特性管理支柱。渐进式委托指的是逐渐将一个功能的控制权委托给对该功能结果最负责的团队（例如，产品经理确保客户对某个功能满意）。这可能看起来像是将一个功能从工程转移到产品管理，然后从产品管理转移到市场营销，等等。特性管理使渐进式交付成为可能，而授权的核心用例就是渐进式委托的典范。</p> 授权是关于让面向客户的团队在软件交付中发挥更大的作用。</p> 授权的程序与构建支柱</a>相似。两者都使用特性标志</a>和用户定向</a>来决定谁在何时看到哪些功能。此外，在每个支柱中，工程师可以将这些功能的交付控制权委托给非工程师——尽管，在构建中工程师做的委托较少。</p> 但是这两个支柱在功能生命周期中的位置不同。构建专注于软件发布前和发布期间的阶段。而授权则涉及期间和之后。它包括长期客户定向，例如为特定企业客户群体提供他们独有的功能集。这只是其中一个例子。</p> 软件组织可以使用特性管理</a>来授权所有团队在以下领域影响软件交付：</p> 功能权限</li> 客户定向</li> 概念验证（POC）和试用</li> 功能淘汰</li> </ol> 授权的目标是什么？</h2> 授权的目标是让面向客户的团队在软件交付中发挥更大的作用。这减轻了工程师的负担，帮助业务利益相关者更有效地完成工作，并创造了更好、更个性化的客户体验。</p> 功能权限</h3> 传统管理权限的方法需要开发者干预。这些方法比必要的更复杂。根据场景，配置权限可能需要工程师更改配置文件（迫使应用程序重新启动）、修改用户数据库、执行自定义构建等。孤立地看，这些动作不是什么大问题。但是当大规模聚合时，它们消耗了大量时间，并带来了不必要的风险。例如，每次你修改用户数据库时，你都有丢失敏感数据、将字段投入混乱和犯其他昂贵错误的风险。</p> 通常，管理权限需要开发者干预。特性管理减轻了工程师的负担，让他们做他们最擅长的事情：构建软件。</p> 除了风险和开销外，传统管理权限的方法还有另一个缺点。它们迫使工程师为客户“开启”和“关闭”功能，而理论上，他们的业务部门同事也可以同样轻松地完成这项工作。事实上，让业务利益相关者控制客户体验更有意义，因为他们经常与这些客户互动。工程师的时间最好花在面向客户团队无法做到的事情上：构建软件！</p> 特性标志减轻了工程的负担，并授权面向客户的团队。以下是一些说明这一点的例子。</p> 授权销售团队管理权限</h4> 一家科技公司，其软件使客户能够在他们的技术栈中检测、管理和保护敏感数据，使用特性管理来管理权限。过去，当客户注册时，销售团队必须提交工程请求，将客户的通用唯一识别码（UUID）添加到配置文件中。只有这样，新客户才能获得他们付费的功能。这个过程使工程师感到压力，对销售团队产生负面影响，并损害了客户体验。</p> 自从使用LaunchDarkly以来，工程师可以将权限的责任交给销售团队。结果，销售人员现在可以为客户提供更快的响应时间。不再有Jira票证，不再等待——只有即时交付的价值。</p> LaunchDarkly如何授权销售团队</h4> LaunchDarkly</a>以以下方式授权销售团队。工程师为与给定软件会员计划（例如，高级计划）相关的功能集创建一个特性标志。然后通过用户定向，他们为这个层级创建一个指定的用户细分。如果用户在这个细分中，他们将看到高级功能。</p> 在这种背景下，每当客户注册高级订阅时，客户经理可以简单地进入LaunchDarkly仪表板，并将新客户添加到适当的细分中。更进一步，你还可以自动化将用户添加到细分的过程。在这种情况下，如果客户在网站上购买订阅，他们将自动出现在正确的细分中，从而立即获得正确的功能。LaunchDarkly因此为权限带来了便利和流畅性。</p> 让我们探索另一个例子。</p> 在一家大型咨询公司自动化权限</h4> 一家大型咨询公司的健康和保健部门使用LaunchDarkly动态控制其新的健康应用程序的行为。LaunchDarkly特性标志根据复杂的业务逻辑和应用内触发器启用和禁用功能。例如，公司只在用户接受条款和条件后才解锁特定功能。当用户升级他们的账户时也是如此。这种自动化提高了公司的反应能力，使开发人员有时间改进产品，而不是分发功能。所有这些都推动了工程师的生产力，并增强了客户体验。</p> 客户定向</h3> 客户定向是另一种权限用例。这种类型的定向范围比离散用户定向更广。它涉及向特定组织、行业、国家和其他大型实体交付功能，每个实体都包含许多个人用户。</p> 这里有一个例子。</p> 白标</h4> 银行提供移动银行应用程序作为他们服务的一部分已经成为常态。在某些情况下，特别是中小银行，银行将从第三方提供商那里购买他们应用程序的核心软件，并将其包装在自己的品牌中（一种被称为“白标”的做法）。</p> 这些第三方提供商在他们的客户组合中有几家银行，他们都想要不同的东西。如果没有特性标志，提供商可能会创建单独的功能分支来交付他们软件的独特版本，有效地为每家银行创建自定义构建。这种方法很难维持。</p> 首先，你对一个分支所做的每一个总体更改都必须在其他分支中复制，以避免失去同步。你做的更改越多，你的代码就越难以驾驭。最终，通过功能分支进行客户定向是耗时的、容易出错的，并且昂贵的。</p> 但是有了特性管理，软件提供商可以使用单个主分支（树干）为每个银行客户交付定制体验。他们可以使用特性标志控制谁看到什么。他们可以在一个代码库中为每个客户构建和交付独特的体验。这种方法是高效的、安全的，并且可控的。</p> 有了特性管理，软件提供商可以为每个客户交付定制体验。</p> 按地理位置定向</h4> 许多软件公司为国际客户服务。他们必须使他们的软件适应每个国家的法律和法规。在一个国家被接受的功能可能在另一个国家被禁止。再次，按国家提供特定功能的一种方式是通过功能分支的混乱来创建你的应用程序的单独实例。我们已经讨论了这种方法的缺点。</p> 但是有了LaunchDarkly，你可以利用特性标志和客户定向，通过国家向正确的客户提供正确的功能——再次，所有这些都在一个代码库中。此外，业务利益相关者可以进行分配。由于业务利益相关者比工程师更了解客户的需求（和法律），让他们管理这些全球客户的权限是明智的。</p> 概念验证（POC）和试用</h3> 对于许多软件公司来说，为潜在客户提供临时访问你的应用程序进行试用和概念验证评估（POC）可能是一个棘手的过程。当销售人员正处于高风险交易的热潮中，他们必须要求工程部门延长试用或发放临时POC许可证，这延长了销售周期。更糟糕的是，它可能完全威胁到交易。POC通常出现在与企业的销售人员的互动中，这些企业的销售涉及数千或数百万美元。你最不想做的事情就是拖延交易，特别是如果潜在客户已经在试用竞争对手的工具。</p> 想象一下，如果销售人员可以自己授权软件访问（当然，有适当的防护措施）？工程师不必担心处理权限请求。销售人员可以更及时地向潜在客户提供功能，增加在交易中超越竞争对手的机会。如果没什么别的，委托功能控制意味着在销售评估中少了一个障碍。</p> 有了特性管理，销售人员确实可以控制试用和POC的软件访问。这正是我们在LaunchDarkly所做的。</p> LaunchDarkly的销售团队使用LaunchDarkly进行POC</h4> 我们的收入团队中的解决方案工程师（SE）使用特性标志在不需要开发者参与的情况下发放试用。标志使我们能够快速为潜在客户以及现有客户组织内的其他群体添加LaunchDarkly座位。我们希望尽可能多的人使用LaunchDarkly的产品，以便他们可以亲身看到它的价值。特性标志在这方面阻止了我们自己的方式。此外，它们还使我们的工程师免于做额外的工作来启用临时和永久功能。</p> 特性标志通过在POC期间向潜在客户提供即时访问你的软件，防止销售评估停滞。</p> 通过为客户开放更多的座位，我们在评估期间提供更多的价值。我们为可能比最初规划的更大的业务案例铺平了道路。更多的座位等于更多的收入。</p> 这种简单的权限管理过程也导致销售人员、工程师和客户更满意。通过LaunchDarkly特性标志，我们授权我们的销售团队为现有和未来的客户做出最佳决策。</p> 功能淘汰</h4> 特性管理是推出新功能的有力解决方案。但它也非常适合淘汰旧功能。</p> 在某些时候，旧功能与新功能冲突，或者它们被废弃并成为技术债务。特性管理为团队提供了对淘汰这些功能的细粒度控制。工程师可以使用特性标志和用户定向来启动淘汰过程。然后，他们可以将标志的控制权委托给产品经理、客户成功代表或与受功能丧失影响的客户有关系的其他人员。面向客户的团队可以按照每个客户的需求的节奏移除旧功能。这给了客户更多的时间来逐渐放弃该功能，从而减轻了过渡的痛苦。</p> LaunchDarkly特性管理平台</a>使您能够管理您的功能的整个生命周期，包括生命周期结束。这在淘汰功能时创造了更好的客户体验。它还通过特性标志为您提供了更多对过程的控制，从而降低了卸载旧功能的风险。</p> 总结：授权的好处</h4> 授权是关于让面向客户的团队控制他们领域内的软件部分。通常，业务利益相关者比开发者更了解客户的需求。然而，从历史上看，他们缺乏控制这些功能如何发布给这些客户的方式。同时，开发者很高兴放弃必须为用户启用功能的永久负担，假设他们可以这样做而没有额外的风险。</p> 特性管理</a>赋予了业务利益相关者他们一直缺失的控制权，这对所有团队都有好处。当工程师构建功能时，他们可以将其移交给业务利益相关者，并说：“嘿，我们将这些功能包装在特性标志中；你们决定它们何时上线，谁可以看到它们等。”每个人都是赢家。</p> 最终，利用特性管理进行权限管理推动了运营效率、提高所有团队的生产力和更好的客户结果。</p> LaunchDarkly’s vision of feature management 2024-10-20T00:00:00+00:00 Software powers the world. LaunchDarkly empowers all teams to deliver and control their software.</h2> Theoretically, teams can engage in all four pillars of feature management without relying on a dedicated feature management tool. In many cases, engineers will construct a patchwork solution for feature flag management in-house. Some organizations, however, do build and use world-class homegrown systems. But in our experience, the latter is the exception. </p> Unsurprisingly, LaunchDarkly contends that, in the long-run, a commercial feature management platform is more affordable, sustainable, and painless than the alternative. You can explore the pros and cons of building vs. buying a feature management solution here</a>.</p> LaunchDarkly’s centralized feature management platform</a>, a software-as-a-service (SaaS) solution, offers a full suite of tools for engaging in all four pillars. It gives teams complete control over every feature in their application. It enables them to build and deliver better software faster, while virtually eliminating risk in the process. Microsoft, IBM, Atlassian, NBC, Intuit, and 4000+ other customers</a> use LaunchDarkly to ship fast, stay safe, and stay in control.</p> We’ve covered a lot of ground in this definitive guide to feature management. The Four Pillars of Feature Management represent a new way of developing software. They embody LaunchDarkly’s vision of feature management. In closing, we want to articulate this vision, so as to illuminate the promised land to which feature management is designed to lead you.</p> Here’s our vision of feature management, a vision we are dedicated to helping you fulfill.</p> Our vision</h2> At LaunchDarkly, we envision a world in which feature releases are safe, boring, and unceremonious</strong>. No more stressful, stomach-turning launch days where developers sit anxiously at their laptops, waiting for something to go wrong. Moreover, we see a day when releases are scheduled and automated—something you “set and forget.” In this world, developers no longer carry the fear of deploying on Fridays at 5. Instead, everyone deploys whenever they please and do so with extreme confidence. </p> We further imagine a world of software development that banishes needless delays and backlogs. Restarts, redeploys, and rollbacks will be a thing of the past. Nor will you have to disable entire feature sets and revert to old versions of your app due to one buggy feature. No more code languishing in pull request (PR) queues or in staging. No more long-lived feature branches</a>. No more merge conflicts. </p> On the contrary, the world we imagine promotes forward motion. In it, software engineers are more productive. Rather than maintain systems and put out fires, they devote themselves to building, creating, and innovating. </p> We envision a world in which most (if not all) new features are wrapped in a feature flag. And when bugs occur, the features responsible are shut off automatically. In this world, flags enable teams to recover from incidents almost as soon as they happen. And customers are completely shielded from these system failures. Teams continuously deliver software while, at the same time, maintaining high stability. </p> We also imagine a world in which software organizations build more things that customers love. No more wasting gobs of time and money building features no one wants—and you’re the last to know. On the contrary, in the world we describe, you experiment with everything. You constantly learn and assess how each code change affects system performance and user behavior. And you draw upon that data to iterate and iterate and iterate until you’ve built something incredible.</p> Finally, at LaunchDarkly, we envision a world in which all</em> teams play a significant role in delivering software. Product managers conduct their own beta tests; marketers hit “go” when they’re ready to unveil new features to customers; and sales and customer success reps manage entitlements. In such a world as this, where all teams are empowered to deliver and control software, fewer disasters occur, engineer burnout plummets, and customer satisfaction rises.</p> It’s a beautiful world, indeed.</p> This is our vision for software development and delivery. We recognize that what we’ve depicted is aspirational and that most organizations will only achieve an approximation of it. That’s ok. The point is to have a clear vision for which to strive.</p> In a software-centered world, one full of peril and uncertainty, control is one of your greatest assets. Feature management gives you that control. And LaunchDarkly gives you feature management in its highest form.</p> 软件驱动世界。LaunchDarkly赋予所有团队交付和控制其软件的能力。</h2> 理论上，团队可以在不依赖专用特性管理工具的情况下参与特性管理的四大支柱。在许多情况下，工程师会构建一个内部的拼凑解决方案来管理特性标志。然而，有些组织确实构建并使用了世界级的自制系统。但根据我们的经验，后者是例外。</p> 不足为奇，LaunchDarkly认为，从长远来看，商业特性管理平台比替代方案更经济、更可持续、更无痛。你可以在这里探索自建与购买特性管理解决方案的利弊</a>。</p> LaunchDarkly的集中式特性管理平台</a>，一个软件即服务（SaaS）解决方案，提供了一整套工具，用于参与所有四大支柱。它赋予团队对其应用程序中的每个功能的完全控制权。它使他们能够更快地构建和交付更好的软件，同时几乎消除了过程中的风险。微软、IBM、Atlassian、NBC、Intuit和4000多个其他客户</a>使用LaunchDarkly快速发货，保持安全，并保持控制。</p> 在这个关于特性管理的终极指南中，我们已经涵盖了很多内容。特性管理的四大支柱代表了一种新的软件开发方式。它们体现了LaunchDarkly对特性管理的愿景。最后，我们想阐明这一愿景，以便照亮特性管理旨在引导你前往的应许之地。</p> 这是我们对特性管理的愿景，我们致力于帮助您实现这一愿景。</p> 我们的愿景</h2> 在LaunchDarkly，我们设想一个特性发布是安全、乏味且不张扬的世界。再也没有紧张的、令人胃痛的发布日，开发者焦虑地坐在他们的笔记本电脑前，等待出现问题。此外，我们看到了发布被安排和自动化的一天——一些你“设置并忘记”的事情。在这个世界里，开发者不再害怕在周五下午5点部署。相反，每个人在他们愿意的时候部署，并且充满极大的信心。</p> 我们进一步想象一个消除了不必要的延迟和积压的软件开发世界。重启、重新部署和回滚将成为过去。你也不必因为一个有缺陷的功能而禁用整个功能集并回退到应用程序的旧版本。不再有代码在拉取请求（PR）队列中或在暂存环境中滞留。不再有长期存在的功能分支</a>。不再有合并冲突。</p> 相反，我们想象的世界促进了前进。在其中，软件工程师更加高效。他们不是维护系统和扑灭火灾，而是致力于构建、创造和创新。</p> 我们设想一个大多数（如果不是全部）新功能都被包裹在特性标志中的世界。当出现错误时，负责的功能会自动关闭。在这个世界里，标志使团队能够几乎立即从事件中恢复。客户完全免受这些系统故障的影响。团队持续交付软件，同时保持高稳定性。</p> 我们还想象一个软件组织构建更多客户喜爱的事物的世界。不再浪费大量时间和金钱构建没有人想要的功能——而你是最后一个知道的。相反，在我们描述的世界中，你尝试一切。你不断学习和评估每次代码更改如何影响系统性能和用户行为。你利用这些数据进行迭代、迭代、再迭代，直到你构建了令人难以置信的东西。</p> 最后，在LaunchDarkly，我们设想一个所有团队在交付软件中发挥重要作用的世界。产品经理自行进行Beta测试；营销人员在准备向客户展示新功能时点击“开始”；销售和客户成功代表管理权限。在这样一个所有团队都被授权交付和控制软件的世界中，发生的灾难更少，工程师的倦怠急剧下降，客户满意度上升。</p> 这确实是一个美丽的世界。</p> 这是我们对软件开发和交付的愿景。我们认识到我们所描绘的是理想的，大多数组织将只实现它的一个近似值。这没关系。关键是有一个清晰的愿景去努力。</p> 在一个以软件为中心的世界里，充满了危险和不确定性，控制是你最大的资产之一。特性管理赋予你这种控制。而LaunchDarkly以最高形式为您提供特性管理。</p> Hexagonal architecture pattern 2024-10-20T00:00:00+00:00 Intent</h2> The hexagonal architecture pattern, which is also known as the ports and adapters pattern, was proposed by Dr. Alistair Cockburn in 2005. It aims to create loosely coupled architectures where application components can be tested independently, with no dependencies on data stores or user interfaces (UIs). This pattern helps prevent technology lock-in of data stores and UIs. This makes it easier to change the technology stack over time, with limited or no impact to business logic. In this loosely coupled architecture, the application communicates with external components over interfaces called ports</em>, and uses adapters</em> to translate the technical exchanges with these components.</p> Motivation</h2> The hexagonal architecture pattern is used to isolate business logic (domain logic) from related infrastructure code, such as code to access a database or external APIs. This pattern is useful for creating loosely coupled business logic and infrastructure code for AWS Lambda functions that require integration with external services. In traditional architectures, a common practice is to embed business logic in the database layer as stored procedures and in the user interface. This practice, along with using UI-specific constructs within business logic, leads to closely coupled architectures that cause bottlenecks in database migrations and user experience (UX) modernization efforts. The hexagonal architecture pattern enables you to design your systems and applications by purpose rather than by technology. This strategy results in easily exchangeable application components such as databases, UX, and service components.</p> Applicability</h2> Use the hexagonal architecture pattern when:</p> You want to decouple your application architecture to create components that can be fully tested.</p> </li> Multiple types of clients can use the same domain logic.</p> </li> Your UI and database components require periodical technology refreshes that don’t affect application logic.</p> </li> Your application requires multiple input providers and output consumers, and customizing the application logic leads to code complexity and lack of extensibility.</p> </li> </ul> Issues and considerations</h2> Domain-driven design</strong>: Hexagonal architecture works especially well with domain-driven design (DDD). Each application component represents a sub-domain in DDD, and hexagonal architectures can be used to achieve loose coupling among application components.</p> </li> Testability</strong>: By design, a hexagonal architecture uses abstractions for inputs and outputs. Therefore, writing unit tests and testing in isolation become easier because of the inherent loose coupling.</p> </li> Complexity</strong>: The complexity of separating business logic from infrastructure code, when handled carefully, can bring great benefits such as agility, test coverage, and technology adaptability. Otherwise, issues can become complex to solve.</p> </li> Maintenance overhead</strong>: The additional adapter code that makes the architecture pluggable is justified only if the application component requires several input sources and output destinations to write to, or when the inputs and output data store has to change over time. Otherwise, the adapter becomes another additional layer to maintain, which introduces maintenance overhead.</p> </li> Latency issues</strong>: Using ports and adapters adds another layer, which might result in latency.</p> </li> </ul> Implementation</h2> Hexagonal architectures support the isolation of application and business logic from infrastructure code and from code that integrates the application with UIs, external APIs, databases, and message brokers. You can easily connect business logic components to other components (such as databases) in the application architecture through ports and adapters.</p> Ports are technology-agnostic entry points into an application component. These custom interfaces determine the interface that allows external actors to communicate with the application component, regardless of who or what implements the interface. This is similar to how a USB port allows many different types of devices to communicate with a computer, as long as they use a USB adapter.</p> Adapters interact with the application through a port by using a specific technology. Adapters plug into these ports, receive data from or provide data to the ports, and transform the data for further processing. For example, a REST adapter enables actors to communicate with the application component through a REST API. A port can have multiple adapters without any risk to the port or to the application component. To extend the previous example, adding a GraphQL adapter to the same port provides an additional means for actors to interact with the application through a GraphQL API without affecting the REST API, the port, or the application.</p> Ports connect to the application, and adapters serve as a connection to the outside world. You can use ports to create loosely coupled application components, and exchange dependent components by changing the adapter. This enables the application component to interact with external input and outputs without needing to have any contextual awareness. Components are exchangeable at any level, which facilitates automated testing. You can test components independently without any dependencies on the infrastructure code instead of provisioning an entire environment to conduct testing. The application logic doesn’t depend on external factors, so testing is simplified and it becomes easier to mock dependencies.</p> For example, in a loosely coupled architecture, an application component should be able to read and write data without knowing the details of the data store. The responsibility of the application component is to supply data to an interface (port). An adapter defines the logic of writing to a data store, which can be a database, a file system, or an object storage system such as Amazon S3, depending on the application’s needs.</p> High-level architecture</h3> The application or application component contains the core business logic. It receives commands or queries from the ports, and sends requests out through the ports to external actors, which are implemented through adapters, as illustrated in the following diagram.</p> </p> Implementation using AWS services</h3> AWS Lambda functions often contain both business logic and database integration code, which are tightly coupled to meet an objective. You can use the hexagonal architecture pattern to separate business logic from infrastructure code. This separation enables unit testing of the business logic without any dependencies on the database code, and improves the agility of the development process.</p> In the following architecture, a Lambda function implements the hexagonal architecture pattern. The Lambda function is initiated by the Amazon API Gateway REST API. The function implements business logic and writes data to DynamoDB tables.</p> </p> Sample code</h3> The sample code in this section shows how to implement the domain model by using Lambda, separate it from infrastructure code (such as the code to access DynamoDB), and implement unit testing for the function.</p> Domain model</h4> The domain model class has no knowledge of external components or dependencies—it only implements the business logic. In the following example, the class Recipient</code> is a domain model class that checks for overlaps in the reservation date.</p> class </span>Recipient</span>: </span> </span>def </span>init</span>(</span>self</span>, </span>recipient_id</span>:str, </span>email</span>:str, </span>first_name</span>:str, </span>last_name</span>:str, </span>age</span>:int): </span> </span>self</span>.__recipient_id </span>= </span>recipient_id </span> </span>self</span>.email </span>= </span>email </span> </span>self</span>.first_name </span>= </span>first_name </span> </span>self</span>.__last_name </span>= </span>last_name </span> </span>self</span>.age </span>= </span>age </span> </span>self</span>.slots </span>= </span>[] </span> </span> @</span>property </span> </span>def </span>recipient_id</span>(</span>self</span>): </span> </span>return </span>self</span>.__recipient_id </span> </span>#..... </span> </span> </span>def </span>are_slots_same_date</span>(</span>self</span>, </span>slot</span>:Slot) -> bool: </span> </span>for </span>selfslot </span>in </span>self</span>.__slots: </span> </span>if </span>selfslot.reservation_date </span>== </span>slot.reservation_date: </span> </span>return </span>True </span> </span>return </span>False </span> </span> </span>def </span>is_slot_counts_equal_or_over_two</span>(</span>self</span>) -> bool: </span> </span>#..... </span></code></pre> Input port</h4> The RecipientInputPort</code> class connects to the recipient class and runs the domain logic.</p> class </span>RecipientInputPort</span>(</span>IRecipientInputPort</span>): </span> </span>def </span>init</span>(</span>self</span>, </span>recipient_output_port</span>: IRecipientOutputPort, </span>slot_output_port</span>: ISlotOutputPort): </span> </span>self</span>.__recipient_output_port </span>= </span>recipient_output_port </span> </span>self</span>.__slot_output_port </span>= </span>slot_output_port </span> </span> </span>''' </span> make reservation: adapting domain model business logic </span> ''' </span> </span>def </span>make_reservation</span>(</span>self</span>, </span>recipient_id</span>:str, </span>slot_id</span>:str) -> Status: </span> status </span>= </span>None </span> </span> </span># --------------------------------------------------- </span> </span># get an instance from output port </span> </span># --------------------------------------------------- </span> recipient </span>= </span>self</span>.__recipient_output_port.</span>get_recipient_by_id</span>(recipient_id) </span> slot </span>= </span>self</span>.__slot_output_port.</span>get_slot_by_id</span>(slot_id) </span> </span> </span>if </span>recipient </span>== </span>None </span>or </span>slot </span>== </span>None</span>: </span> </span>return </span>Status</span>(</span>400</span>, </span>"Request instance is not found. Something wrong!"</span>) </span> </span> </span>print</span>(</span>f</span>"recipient: </span>{recipient.first_name}</span>, slot date: </span>{slot.reservation_date}</span>"</span>) </span> </span> </span># --------------------------------------------------- </span> </span># execute domain logic </span> </span># --------------------------------------------------- </span> ret </span>= </span>recipient.</span>add_reserve_slot</span>(slot) </span> </span> </span># --------------------------------------------------- </span> </span># persistent an instance throgh output port </span> </span># --------------------------------------------------- </span> </span>if </span>ret </span>== </span>True</span>: </span> ret </span>= </span>self</span>.__recipient_output_port.</span>add_reservation</span>(recipient) </span> </span> </span>if </span>ret </span>== </span>True</span>: </span> status </span>= </span>Status</span>(</span>200</span>, </span>"The recipient's reservation is added."</span>) </span> </span>else</span>: </span> status </span>= </span>Status</span>(</span>200</span>, </span>"The recipient's reservation is NOT added!"</span>) </span> </span>return </span>status </span></code></pre> DynamoDB adapter class</h4> The DDBRecipientAdapter</code> class implements access to the DynamoDB tables.</p> class </span>DDBRecipientAdapter</span>(</span>IRecipientAdapter</span>): </span> </span>def </span>init</span>(</span>self</span>): </span> ddb </span>= </span>boto3.</span>resource</span>(</span>'dynamodb'</span>) </span> </span>self</span>.__table </span>= </span>ddb.</span>Table</span>(table_name) </span> </span> </span>def </span>load</span>(</span>self</span>, </span>recipient_id</span>:str) -> Recipient: </span> </span>try</span>: </span> response </span>= </span>self</span>.__table.</span>get_item</span>( </span> </span>Key</span>=</span>{</span>'pk'</span>: pk_prefix </span>+ </span>recipient_id}) </span> 　</span>... </span> </span> </span>def </span>save</span>(</span>self</span>, </span>recipient</span>:Recipient) -> bool: </span> </span>try</span>: </span> item </span>= </span>{ </span> </span>"pk"</span>: pk_prefix </span>+ </span>recipient.recipient_id, </span> </span>"email"</span>: recipient.email, </span> </span>"first_name"</span>: recipient.first_name, </span> </span>"last_name"</span>: recipient.last_name, </span> </span>"age"</span>: recipient.age, </span> </span>"slots"</span>: [] </span> } </span> </span># ... </span></code></pre> The Lambda function get_recipient_input_port</code> is a factory for instances of the RecipientInputPort</code> class. It constructs instances of output port classes with related adapter instances.</p> def </span>get_recipient_input_port</span>(): </span> </span>return </span>RecipientInputPort</span>( </span> </span>RecipientOutputPort</span>(</span>DDBRecipientAdapter</span>()), </span> </span>SlotOutputPort</span>(</span>DDBSlotAdapter</span>())) </span> </span>def </span>lambda_handler</span>(</span>event</span>, </span>context</span>): </span> </span> body </span>= </span>json.</span>loads</span>(event[</span>'body'</span>]) </span> recipient_id </span>= </span>body[</span>'recipient_id'</span>] </span> slot_id </span>= </span>body[</span>'slot_id'</span>] </span> </span> </span># get an input port instance </span> recipient_input_port </span>= </span>get_recipient_input_port</span>() </span> status </span>= </span>recipient_input_port.</span>make_reservation</span>(recipient_id, slot_id) </span> </span> </span>return </span>{ </span> </span>"statusCode"</span>: status.status_code, </span> </span>"body"</span>: json.</span>dumps</span>({ </span> </span>"message"</span>: status.message </span> }), </span> } </span></code></pre> Unit testing</h4> You can test the business logic for domain model classes by injecting mock classes. The following example provides the unit test for the domain model Recipent</code> class.</p> def </span>test_add_slot_one</span>(</span>fixture_recipient</span>, </span>fixture_slot</span>): </span> slot </span>= </span>fixture_slot </span> target </span>= </span>fixture_recipient </span> target.</span>add_reserve_slot</span>(slot) </span> </span>assert </span>slot </span>!= </span>None </span> </span>assert </span>target </span>!= </span>None </span> </span>assert </span>1 </span>== </span>len</span>(target.slots) </span> </span>assert </span>slot.slot_id </span>== </span>target.slots[</span>0</span>].slot_id </span> </span>assert </span>slot.reservation_date </span>== </span>target.slots[</span>0</span>].reservation_date </span> </span>assert </span>slot.location </span>== </span>target.slots[</span>0</span>].location </span> </span>assert </span>False </span>== </span>target.slots[</span>0</span>].is_vacant </span> </span>def </span>test_add_slot_two</span>(</span>fixture_recipient</span>, </span>fixture_slot</span>, </span>fixture_slot_2</span>): </span> </span>#..... </span> </span>def </span>test_cannot_append_slot_more_than_two</span>(</span>fixture_recipient</span>, </span>fixture_slot</span>, </span>fixture_slot_2</span>, </span>fixture_slot_3</span>): </span> </span>#..... </span> </span>def </span>test_cannot_append_same_date_slot</span>(</span>fixture_recipient</span>, </span>fixture_slot</span>): </span> </span>#..... </span></code></pre> GitHub repository</h4> For a complete implementation of the sample architecture for this pattern, see the GitHub repository at https://github.com/aws-samples/aws-lambda-domain-model-sample</a>.</p> Related content</h2> Hexagonal architecture</a>, article by Alistair Cockburn</p> </li> Developing evolutionary architectures with AWS Lambda</a> (AWS blog post in Japanese)</p> </li> </ul> Improving flag usage in code 2024-10-20T00:00:00+00:00 Improving flag usage in code</h1> Read time: 10 minutes</h5> Last edited: Sep 18, 2024</h5> </a>Overview</h2> This guide provides best practices and suggestions for improving code that uses feature flags. These practices can improve both code quality and ease of maintenance.</p> You can use code in tandem with your feature flags to maintain and improve the resilience of your process, including improving flag hygiene, giving your team more flexibility, refactoring flagged code to the degree that you need and no further, and generally increasing code quality.</p> Not all best practices work for everyone</p> The practices we offer in this guide are subjective. What may be a best practice for one team may not work as well for another. Review the recommendations in this guide and consider carefully if they will help your team before you implement them.</p> </a>Concepts</h2> In order to use this guide effectively, you should understand these concepts:</p> </a>Improve flag hygiene</h3> Most of the flags added to a project are temporary, intended to be removed later. Unfortunately, most teams are worse at removing flags than adding them, because removal is usually less urgent. This can lead to a codebase cluttered with flags that are no longer relevant. At best, this makes the code harder to read; at worst, inadvertently toggling the wrong flag can cause production failures.</p> Teams that use flags need to ensure that their code only references flags which are currently in use. This practice is known as “flag hygiene.” Here is a selection of techniques that help maintain good flag hygiene.</p> To learn more about flag hygiene, read Reducing technical debt from feature flags</a>.</p> </a>Extend your team’s “definition of done”</h3> Engineering teams maintain their own standards for when a task or project can be considered “done.” For example, a team may consider the code for a task to be incomplete until it has automated tests.</p> You can maintain flag hygiene by ensuring that the temporary flags created for a task or project are no longer referenced by any code and are archived after they’re no longer in use. Adding this as a requirement to your team’s definition of done may help streamline your codebase, because only the flags you’re actively using will be present in it.</p> Code standards are easier to maintain with automated checks, such as those performed by a continuous integration (CI) system. You can even automate some flag hygiene checks.</p> </a>Use code references to track flag hygiene</h2> LaunchDarkly’s code references</a> feature keeps track of the places in your code where each flag appears. It’s particularly useful when you need to clean up old flags.</p> Ensure that the code references for your project are up to date by integrating the ld-find-code-refs</code></a> tool with your code pipeline.</p> To learn more, read Code references</a>.</p> Here is an image of the code references section for a feature flag:</p> </p> The code references section of a feature flag.</p> </a>Refactor flagged code to reduce merge conflicts</h2> Merge conflicts are a common source of friction when you make code changes. Adding flag logic in the middle of a function increases the chances that both that addition and its removal later will conflict with other changes.</p> To reduce the chance of conflicts, refactor both the flag logic and the code for each variation into their own functions. Keep the refactoring simple so that the overall time spent implementing the flag is short.</p> The examples below do not use a real coding language</p> The examples below use an approximation of a real coding language to illustrate the concepts they express. The language is based on JavaScript, but is not JavaScript.</p> Do not use these code samples in a production environment. They will not work.</p> Here’s an example to demonstrate this factoring tactic. The example code is taken from a fictional app which has a search feature which queries a back-end search engine. In the existing code, the function getSearchResults</code> does the work of sending the search query to the backend, checking for errors and fetching the results.</p> Here is an example:</p> pseudocode</p> function getSearchResults(query, context) {</p> // 1. parse the query so engine can use it</p> // … query parsing logic goes here…</p> // 2. send the search query to the back-end search engine</p> engineURL = SEARCH_ENGINE_URL + ‘/search’;</p> response = sendRequest(engineURL, parsedQuery);</p> // 3. check for errors</p> if (response.body.starts_with(“SEARCH ERROR”)) {</p> // if there's an error, log the response and context details </span> </span>log.ERROR("Search failure", response, context); </span> </span>return new Error("There was an internal search error."); </span></code></pre> } else {</p> // 4. turn response into a result list, clean up the results, etc. </span> </span>// ... results logic goes here... </span> </span>return results; </span></code></pre> }</p> }</p> COPY</p> The app’s engineering team is preparing to migrate to a new, improved search engine. To prepare for the migration, the team has created the flag use-new-search-engine</code> to tell the app which search back-end to use. The code needs to include code for querying both the old and the new search engines.</p> Inserting the flag logic in the middle of getSearchResults</code> would make it even more complicated than it is already. Instead, they extract the relevant code and move it to new functions. They take the code which sends the query to the search engine (section 2 in the code above) and also code which processes errors and results (sections 3 and 4), because the new engine returns errors and results in a different format.</p> The team moves these lines of code, along with code for the new search engine and code to check the flag, into their own functions:</p> pseudocode</p> // This new version of the main function is much shorter,</p> // because it delegates the central work to executeSearch()</p> function getSearchResults(query, context) {</p> // 1. parse the query so engine can use it</p> // … query parsing logic goes here…</p> // 2. send the search query to the back-end search engine</p> response = executeSearch(parsedQuery, context);</p> return response;</p> }</p> // This function only checks the value of the “use-new-search-engine” flag</p> // and routes the query to one of the two functions below</p> // to do the actual querying and processing</p> function executeSearch(query, context) {</p> useNewEngine = ldclient.variation(“use-new-search-engine”, context, false);</p> if (useNewEngine == true) {</p> return queryNewEngine(query, context); </span></code></pre> } else {</p> return queryOldEngine(query, context); </span></code></pre> }</p> }</p> // This function queries the OLD search engine and processes the response</p> function queryOldEngine(query, context) {</p> engineURL = SEARCH_ENGINE_URL + ‘/search’;</p> response = sendRequest(engineURL, query);</p> if (response.body.starts_with(“SEARCH ERROR”)) {</p> log.ERROR("Search failure on old engine", response, context); </span> </span>return new Error("There was an internal search error."); </span></code></pre> } else {</p> // turn response into result list, clean up the results, etc. </span> </span>// ... results logic goes here... </span> </span>return results; </span></code></pre> }</p> }</p> // This function queries the NEW search engine and processes the response</p> function queryNewEngine(query, context) {</p> engineURL = NEW_SEARCH_ENGINE_URL + ‘/query’;</p> response = sendRequest(engineURL, query);</p> if (response.type == “error”) {</p> log.ERROR("Search failure on new engine", response, context); </span> </span>return new Error("There was an internal search error."); </span></code></pre> } else {</p> // turn new-engine response into a result list </span> </span>// ... results logic goes here... </span> </span>return results; </span></code></pre> }</p> }</p> COPY</p> The migration is expected to last a few weeks. Because the new feature is wrapped in a feature flag, the team can integrate the new search engine code before it’s been fully tested and optimized. Now, they can spend time improving the code with real production data. Because the new and old search engine code is separated into different functions, they can make those improvements without changing shared code. In addition, it’s easier to add unit tests for the new code because they can call it directly without needing to create mock flag states.</p> When it’s time to retire the old search engine and archive the feature flag, the cleanup is minimal and less likely to cause merge conflicts.</p> The cleanup steps are:</p> Delete the executeSearch</code> and queryOldEngine</code> functions.</li> Rename queryNewEngine</code> to executeSearch</code>.</li> Within queryNewEngine</code>, change the log.ERROR</code> message from "Search failure on new engine"</code> to just "Search failure"</code>, because there is only one engine now.</li> </ol> </a>Avoid additional refactoring</h3> Both queryOldEngine</code> and queryNewEngine</code> contain similar code. Another version of this example could even contain more lines of code which are duplicated between both functions. You might want to refactor further by moving the duplicated code into a shared function.</p> There are a couple of reasons not to deduplicate code.</p> The code is not intended for long-term maintenance. After the migration is finished, the duplicates are deleted.</li> There is likely to be short-term</em> maintenance as you improve queryNewEngine</code>. Premature refactoring may hinder that maintenance more than it helps.</li> </ul> We recommend the common refactoring adage known as the rule of three</em></a>: don’t refactor for deduplication until code is duplicated three or more times.</p> </a>Improve code quality</h2> Adding feature flags to code increases its flexibility, but can also add complexity. The more complex your code is, the more difficult it is to diagnose and correct an unexpected problem.</p> There are various techniques you can use to make sure that your feature flags help accomplish what you want to do with code.</p> Here are some guidelines you can follow to make sure you write high-quality code:</p> </a>Avoid passing flag state in a call interface</h3> When you use a feature flag to change the behavior of a component, perform the flag evaluation inside</em> the component.</p> It can be tempting to add a dedicated parameter to the call interface and send the flag state from the outside. However, changing the component’s interface means that all the component’s callers have to be changed too, and then changed again once the flag is removed.</p> Consider the executeSearch</code> function we used as an example earlier. It calls ldclient.variation</code> to evaluate the flag from within its own implementation.</p> If we moved that call out to getSearchResults</code> and sent the flag value to executeSearch</code> as an argument, the abbreviated code would look like this:</p> pseudocode</p> function getSearchResults(query, context) {</p> // 1. parse the query so engine can use it</p> // … query parsing logic goes here…</p> // 2. send the search query to the back-end search engine</p> // with the feature flag value</p> useNewEngine = ldclient.variation(“use-new-search-engine”, context, false);</p> response = executeSearch(parsedQuery, context, useNewEngine);</p> return response;</p> }</p> // useNewEngine</code> is now supplied in the call</p> function executeSearch(query, context, useNewEngine) {</p> if (useNewEngine == true) {</p> return queryNewEngine(query, context); </span></code></pre> } else {</p> return queryOldEngine(query, context); </span></code></pre> }</p> }</p> COPY</p> The purpose of our flag-oriented refactoring was to reduce merge conflicts by separating out the code that would need to change, and keeping it contained in dedicated functions. Unfortunately, putting the flag evaluation code in getSearchResults</code> has given it more responsibility that it didn’t need, and removed the benefits of the refactoring.</p> In this example, the changed interface only had one caller. When changing functions and modules with many callers, there’s even greater benefit in keeping the interface the same. This is especially important given the other risks inherent in changing heavily-used code.</p> </a>Flags can change any time</h3> The more frequently that your code is executed, the more likely it is that your code will be in the middle of executing when a vital flag is changed. If your code is constructed in a way that expects flag state to stay consistent between the start and end of a code path, it can cause problems that are particularly hard to debug.</p> One way to avoid this problem is to use LaunchDarkly’s custom roles feature to restrict who can access the flag.</p> To learn more, read Custom roles</a>.</p> This can make it harder to change a flag, which can be good in some cases, but it also increases the friction in your development process. Instead of making change more difficult, it’s better to improve the robustness of your code.</p> The following example uses a service that sends batches of data through a processing pipeline. Each batch must go through three processing steps: normalization, relabeling, and storage.</p> A dedicated service performs each of these steps. The storage step is always the last, but the normalization and relabeling can happen in either order. Each service is responsible for sending the data batch to the next service.</p> There are two possible orders in which the processing steps can be performed. The order is chosen using a feature flag called process-order</code> which has variations normalize-first</code> and relabel-first</code>.</p> The normalize-first</code> order is:</p> Normalization</li> Relabeling</li> Storage</li> </ol> The relabel-first</code> order looks like this:</p> Relabeling</li> Normalization</li> Storage</li> </ol> Each service is responsible for sending its output to the next step.</p> It’s tempting to have each service evaluate the process-order</code> flag after it’s processed and use this to decide the next step. However, if the flag is flipped in the middle of processing, this could cause problems.</p> If the flag is set to normalize-first</code>, the batch starts at the normalization service. Before that service finishes processing, someone flips the flag to enable the relabel-first</code> process. When the normalization service finishes processing, it’ll evaluate the process-order</code> flag and use the relabel-first</code> ordering, in which the normalization step is followed by storage. This data batch should be sent to the relabeling service because it hasn’t been relabeled, but it will be sent to storage instead.</p> This is an example of a situation in which flag consistency is required throughout multiple steps. The flag should be evaluated once for each batch, and that value should be sent in the call from service to service.</p> </a>Conclusion</h2> In this guide, we covered:</p> Using code references to find feature flags in your codebase</li> When and how to refactor to streamline your code</li> How to improve code quality with flags</li> </ul> 提高代码中特性标志使用的最佳实践</p> 阅读时间：10分钟</h4> 最后编辑：2024年9月18日</h4> </a>概览</h2> 本指南提供了最佳实践和建议，以改善使用特性标志的代码。这些实践可以提高代码质量和维护的便利性。</p> 您可以将代码与特性标志一起使用，以维护和提高您流程的弹性，包括改善标志卫生、为团队提供更多灵活性、在需要的程度上重构标志代码，以及普遍提高代码质量。</p> 并非所有最佳实践都适用于每个人</p> 本指南中提供的做法是主观的。对于一个团队来说可能是最佳实践，对于另一个团队可能效果不佳。在实施之前，请仔细考虑这些建议是否能帮助您的团队。</p> </a>概念</h2> 为了有效地使用本指南，您应该理解以下概念：</p> </a>提高标志卫生</h3> 项目中添加的大多数标志都是临时的，打算稍后移除。不幸的是，大多数团队在移除标志方面比添加标志更差，因为移除通常不那么紧迫。这可能导致代码库中充满了不再相关的标志。这在最好的情况下会使代码更难阅读；在最坏的情况下，不小心切换错误的标记可能会导致生产失败。</p> 使用标志的团队需要确保他们的代码只引用当前正在使用的标志。这种实践被称为“标志卫生”。以下是一些有助于维护良好标志卫生的技术。</p> 要了解更多关于标志卫生的信息，请阅读减少特性标志的技术债务</a>。</p> </a>扩展团队的“完成定义”</h3> 工程团队维护自己的标准，以确定何时可以认为任务或项目“完成”。例如，一个团队可能认为，除非代码有自动化测试，否则任务的代码不完整。</p> 您可以通过确保为任务或项目创建的临时标志不再被任何代码引用，并且在不再使用后被归档，来维护标志卫生。将此作为团队完成定义的要求，可能有助于简化您的代码库，因为只有您正在积极使用的标记才会出现在其中。</p> 通过持续集成（CI）系统执行的自动化检查，更容易维护代码标准。您甚至可以自动化一些标志卫生检查。</p> </a>使用代码引用跟踪标志卫生</h2> LaunchDarkly的代码引用</a>功能跟踪您的代码中每个标志出现的位置。当您需要清理旧标志时，它特别有用。</p> 通过将</a>工具集成到您的代码管道中，确保您的项目的代码引用是最新的。</p> 要了解更多信息，请阅读代码引用</a>。</p> 这里是功能标志的代码引用部分的图片：</p> </a></p> 功能标志的代码引用部分。</p> </a>重构标志代码以减少合并冲突</h2> 合并冲突是进行代码更改时常见的摩擦源。在函数中间添加标志逻辑会增加该添加及其后续删除与其他更改冲突的可能性。</p> 为了减少冲突的机会，重构标志逻辑和每个变体的代码到它们自己的函数中。保持重构简单，以便实现标志的总时间很短。</p> 下面的示例不使用真正的编程语言</p> 下面的示例使用近似于真实编程语言的示例来说明它们表达的概念。该语言基于JavaScript，但不是JavaScript。</p> 不要将这些代码示例用于生产环境。它们将无法工作。</p> 以下是一个演示这种分解策略的示例。示例代码来自一个虚构的应用程序，该应用程序具有查询后端搜索引擎的搜索功能。在现有代码中，函数getSearchResults</code>负责将搜索查询发送到后端、检查错误并获取结果。</p> 以下是一个示例：</p> 伪代码</p> function getSearchResults(query, context) { </span> </span> // 1. 解析查询以便引擎可以使用 </span> </span> // ...查询解析逻辑在这里... </span> </span> // 2. 将搜索查询发送到后端搜索引擎 </span> </span> engineURL = SEARCH_ENGINE_URL + '/search'; </span> </span> response = sendRequest(engineURL, parsedQuery); </span> </span> // 3. 检查错误 </span> </span> if (response.body.starts_with("SEARCH ERROR")) { </span> </span> // 如果有错误，记录响应和上下文详细信息 </span> </span> log.ERROR("Search failure", response, context); </span> </span> return new Error("There was an internal search error."); </span> </span> } else { </span> </span> // 4. 将响应转换为结果列表，清理结果等 </span> </span> // ...结果逻辑在这里... </span> </span> return results; </span> </span> } </span> </span>} </span></code></pre> 应用程序的工程团队正准备迁移到一个新的、改进的搜索引擎。为了准备迁移，团队创建了标志use-new-search-engine</code>来告诉应用程序使用哪个搜索后端。代码需要包括查询旧搜索引擎和新搜索引擎的代码。</p> 在getSearchResults</code>中间插入标志逻辑会使它比已经复杂的情况更加复杂。相反，他们提取相关代码并将其移动到新函数中。他们将发送查询到搜索引擎的代码（上述代码中的第2部分）以及处理错误和结果的代码（第3和第4部分），因为新引擎以不同的格式返回错误和结果。</p> 团队将这些代码行，以及新搜索引擎的代码和检查标志的代码，移动到它们自己的函数中：</p> 伪代码</p> // 这个主函数的新版本更短， </span> </span>// 因为它将中心工作委托给executeSearch() </span> </span>function getSearchResults(query, context) { </span> </span> // 1. 解析查询以便引擎可以使用 </span> </span> // ...查询解析逻辑在这里... </span> </span> // 2. 将搜索查询发送到后端搜索引擎 </span> </span> response = executeSearch(parsedQuery, context); </span> </span> return response; </span> </span>} </span> </span>// 这个函数只检查“use-new-search-engine”标志的值 </span> </span>// 并将查询路由到下面的两个函数之一 </span> </span>// 执行实际的查询和处理 </span> </span>function executeSearch(query, context) { </span> </span> useNewEngine = ldclient.variation("use-new-search-engine", context, false); </span> </span> if (useNewEngine == true) { </span> </span> return queryNewEngine(query, context); </span> </span> } else { </span> </span> return queryOldEngine(query, context); </span> </span> } </span> </span>} </span> </span>// 这个函数查询旧搜索引擎并处理响应 </span> </span>function queryOldEngine(query, context) { </span> </span> engineURL = SEARCH_ENGINE_URL + '/search'; </span> </span> response = sendRequest(engineURL, query); </span> </span> if (response.body.starts_with("SEARCH ERROR")) { </span> </span> log.ERROR("Search failure on old engine", response, context); </span> </span> return new Error("There was an internal search error."); </span> </span> } else { </span> </span> // 将响应转换为结果列表，清理结果等 </span> </span> // ...结果逻辑在这里... </span> </span> return results; </span> </span> } </span> </span>} </span> </span>// 这个函数查询新搜索引擎并处理响应 </span> </span>function queryNewEngine(query, context) { </span> </span> engineURL = NEW_SEARCH_ENGINE_URL + '/query'; </span> </span> response = sendRequest(engineURL, query); </span> </span> if (response.type == "error") { </span> </span> log.ERROR("Search failure on new engine", response, context); </span> </span> return new Error("There was an internal search error."); </span> </span> } else { </span> </span> // 将新引擎响应转换为结果列表 </span> </span> // ...结果逻辑在这里... </span> </span> return results; </span> </span> } </span> </span>} </span></code></pre> 预计迁移将持续几周。由于新特性被包装在特性标志中，团队可以在新搜索引擎代码完全测试和优化之前集成它。现在，他们可以花时间使用真实生产数据改进代码。由于新旧搜索引擎代码被分离到不同的函数中，他们可以在不更改共享代码的情况下进行这些改进。此外，由于可以直接调用新代码而无需创建模拟标志状态，因此更容易为新代码添加单元测试。</p> 当需要退役旧搜索引擎并归档特性标志时，清理工作最少，不太可能引起合并冲突。</p> 清理步骤如下：</p> 删除executeSearch</code>和queryOldEngine</code>函数。</li> 将queryNewEngine</code>重命名为executeSearch</code>。</li> 在queryNewEngine</code>中，将log.ERROR</code>消息从"Search failure on new engine"</code>更改为仅"Search failure"</code>，因为现在只有一个引擎了。</li> </ol> 避免额外的重构</h3> queryOldEngine</code> 和 queryNewEngine</code> 都包含类似的代码。这个示例的另一个版本甚至可能包含更多在两个函数之间重复的代码行。您可能想要通过将重复的代码移动到一个共享函数中来进一步重构。</p> 有几个原因不进行代码去重。</p> 代码并非为长期维护而设计。迁移完成后，重复的代码将被删除。</li> 在您改进 queryNewEngine</code> 时，可能会有短期的维护工作。过早的重构可能会比帮助更多地阻碍维护。</li> </ul> 我们推荐一个常见的重构格言，称为《三的法则》</a>：在代码重复三次或更多次之前，不要为了去重而进行重构。</p> 提高代码质量</h2> 在代码中添加特性标志增加了其灵活性，但也可能增加复杂性。代码越复杂，诊断和纠正意外问题就越困难。</p> 您可以使用各种技术来确保特性标志帮助您实现代码的目标。</p> 以下是一些您可以遵循的指导方针，以确保您编写高质量的代码：</p> 避免在调用接口中传递标志状态</h3> 当您使用特性标志来改变组件的行为时，请在组件内部</strong>执行标志评估。</p> 可能很想在调用接口中添加一个专用参数，并从外部发送标志状态。然而，改变组件的接口意味着所有调用该组件的代码也必须改变，一旦标志被移除，又需要再次改变。</p> 考虑我们之前用作示例的 executeSearch</code> 函数。它调用 ldclient.variation</code> 在其自己的实现内部评估标志。</p> 如果我们将那个调用移到 getSearchResults</code> 并将标志值作为参数传递给 executeSearch</code>，简化后的代码将如下所示：</p> 伪代码</p> function getSearchResults(query, context) { </span> // 1. 解析查询以便引擎可以使用 </span> </span> // ...查询解析逻辑在这里... </span> </span> // 2. 将搜索查询发送到后端搜索引擎 </span> </span> // 带有特性标志值 </span> </span> useNewEngine = ldclient.variation("use-new-search-engine", context, false); </span> </span> response = executeSearch(parsedQuery, context, useNewEngine); </span> </span> return response; </span>} </span> </span>// `useNewEngine` 现在在调用中提供 </span> </span>function executeSearch(query, context, useNewEngine) { </span> if (useNewEngine == true) { </span> return queryNewEngine(query, context); </span> } else { </span> return queryOldEngine(query, context); </span> } </span>} </span></code></pre> 我们以标志为导向的重构目的是为了通过分离出需要改变的代码，并将其包含在专用函数中，来减少合并冲突。不幸的是，在 getSearchResults</code> 中放入标志评估代码，给它带来了它不需要的更多责任，并消除了重构的好处。</p> 在这个例子中，改变的接口只有一个调用者。当改变有多个调用者的函数和模块时，保持接口不变的好处更大。鉴于改变频繁使用的代码的其他风险，这一点尤其重要。</p> 标志可以随时改变</h3> 您的代码执行得越频繁，当一个关键标志被改变时，您的代码在执行中途的可能性就越大。如果您的代码构建方式期望标志状态在代码路径的开始和结束之间保持一致，它可能会导致特别难以调试的问题。</p> 避免这个问题的一种方法是使用 LaunchDarkly 的自定义角色功能来限制谁可以访问该标志。</p> 要了解更多信息，请阅读自定义角色</a>。</p> 这可能会使改变标志变得更加困难，在某些情况下可能是好事，但它也增加了您开发过程中的摩擦。与其使改变更加困难，不如提高代码的健壮性。</p> 以下示例使用一个服务，该服务将批量数据通过处理管道发送。每个批次必须经过三个处理步骤：规范化、重新标记和存储。</p> 一个专用服务执行这些步骤中的每一个。存储步骤始终是最后一个，但规范化和重新标记可以以任何顺序发生。每个服务负责将数据批次发送到下一个服务。</p> 有两种可能的顺序可以执行处理步骤。顺序是使用一个名为 process-order</code> 的特性标志选择的，该标志有 normalize-first</code> 和 relabel-first</code> 两种变化。</p> normalize-first</code> 顺序是：</p> 规范化</li> 重新标记</li> 存储</li> </ol> relabel-first</code> 顺序如下：</p> 重新标记</li> 规范化</li> 存储</li> </ol> 每个服务负责将其输出发送到下一步。</p> 在每个服务处理后评估 process-order</code> 标志并使用此来决定下一步是很诱人的。然而，如果在处理中途标志被翻转，这可能会导致问题。</p> 如果标志被设置为 normalize-first</code>，则批次从规范化服务开始。在该服务完成处理之前，有人翻转了标志以启用 relabel-first</code> 过程。当规范化服务完成处理时，它将评估 process-order</code> 标志并使用 relabel-first</code> 顺序，在该顺序中，规范化步骤后跟存储。这个数据批次应该被发送到重新标记服务，因为它还没有被重新标记，但它将被发送到存储服务。</p> 这是一个需要在整个多个步骤中保持标志一致性的情况示例。标志应该为每个批次评估一次，并且该值应该在服务之间的调用中发送。</p> 结论</h2> 在本指南中，我们涵盖了：</p> 使用代码引用在您的代码库中找到特性标志</li> 何时以及如何重构以简化您的代码</li> 如何通过标志提高代码质量</li> </ul> Reducing technical debt from feature flags 2024-10-20T00:00:00+00:00 Reducing technical debt from feature flags</h1> Read time: 16 minutes</h5> Last edited: Oct 15, 2024</h5> </a>Overview</h2> This guide provides ways to reduce and eliminate technical debt related to feature flags using LaunchDarkly. Like all debt, technical debt accumulates over time, but you can mitigate that debt over time if you put effective processes in place before you need them.</p> In this guide, we’ll explore:</p> The challenge of technical debt</li> The lifecycle of a flag</li> Naming conventions</li> Using tags</li> Code references</li> Deprecating, archiving, and deleting flags</li> </ul> Just like feature flags should be a core engineering practice, so should a strategy to address technical debt. LaunchDarkly can help you by automatically identifying flags that need code removal or are ready to archive.</p> </a>Prerequisites</h2> To complete this guide, you must have the following prerequisites:</p> Proficiency and understanding of creating a feature flag in LaunchDarkly</li> Knowledge of your organization’s release process</li> </ul> </a>Concepts</h2> You should understand these concepts before you read this guide:</p> </a>Technical debt</h3> Technical debt is a concept in software development that describes the implied cost of rework required in the future because of short-term, limited solutions. It is often caused by choosing a fast, limited solution now instead of using a better approach that would take longer. A common reason for this is that necessary work must be delayed to meet a deliverable or a deadline.</p> As this debt accumulates, it is harder to maintain the system and code, which can impact the speed of development and efficiency of your codebase in the future.</p> One way technical debt can accumulate is when you fail to maintain your feature flags.</p> </a>Software delivery lifecycle</h3> The software delivery lifecycle (SDLC) is a process followed for a software project. The process describes how to develop, maintain, and modify software. The stages of the software delivery cycle are:</p> Planning</li> Analysis</li> Design</li> Implementation</li> Testing and integration</li> Maintenance</li> </ul> </a>Temporary and permanent flags</h3> Flags are either temporary or permanent. A temporary flag has a limited lifespan. Once the flag has fulfilled its business purpose, remove it from the codebase. Temporary flags include flags for release management, experiments, and interoperability testing.</p> Permanent flags provide control for an extended time after the release of a feature. They will potentially exist for the life of a feature. Permanent flags include flags for entitlements, load shedding, custom-branding, or accessibility.</p> </a>Challenges of technical debt</h2> Every feature should have a flag, but if you don’t regularly archive flags, you can accumulate a lot of debt.</p> Cluttered code is harder to maintain and test. Unnecessary code remains because nobody remembers why it existed, and there is a fear that things will break if it is removed. Failure to remove flags leads to cluttered code.</p> Not only do you want to remove the references to the flag in your code, but you also don’t want to send evaluation settings for flags you don’t need. When you use features like Data Export to track the impact of your rollouts, your database may be overwhelmed with unnecessary event data. You don’t want to transfer and store data on flags that should have been archived three months ago.</p> Failure to remove flags clutters your Flags</strong> list, as well as your code. You can’t quickly find the flag you need to toggle. This may seem like a minor inconvenience, but if you need to quickly toggle a flag’s targeting off, having to scroll through hundreds of flags adds time. But cluttered code and extensive Flags</strong> lists aren’t the only challenges.</p> You also run the risk of an old flag evaluating to a state that is invalid or undesirable. When you’re rolling out a new change such as an updated user interface (UI), it is common to keep the current UI as the default version until you have confidence in the new one. Once the flag is serving 100% of contexts the new UI, the flag has reached the end of its lifecycle and should be archived. Failure to do this runs the risk of falling back to the undesired old UI if a flag gets turned off or an SDK failure results in using the fallback value.</p> Test the fallback values of permanent flags periodically to ensure they are up to date and delivering valid states. To learn more about fallback values, read Change default flag values</a>.</p> </a>The flag lifecycle</h2> A flag may go through several stages over the course of its lifecycle, including:</p> Live</li> Ready for code removal</li> Ready to archive</li> Archived</li> Deprecated</li> Deleted</li> </ul> The lifecycle stage is based on what is happening across all environments. Not all flags will go through all lifecycle stages.</p> Flags are ready for code removal if they are temporary flags that are either not being evaluated any more (“Inactive” status), or are serving the same variation to all contexts (“Launched” status). An “Inactive” status may mean that you’re no longer running the code which evaluates the flag. A “Launched” status likely means that any gradual rollout of a new feature has ended, and the feature is now live for all contexts. The flag is still evaluated every time the code is run, but because it returns the same variation for everyone, it’s no longer needed. You should now either remove the flag from your code and then archive the flag, or turn the flag into a permanent flag that you can use as a circuit breaker to disable the feature entirely.</p> For example, consider this flag:</p> </a></p> A flag with status of “Inactive” and a lifecycle stage of “Ready to archive.”</p> This flag’s status is “Inactive,” and it is marked as “Ready to archive.” No one is using the flag. You can remove it from your code and archive it.</p> LaunchDarkly automatically determines if a flag is ready to archive by checking the flag in all of your critical environments</a> for code references, age, status, and whether it is a prerequisite. You can view flags that are ready to archive from the Flags</strong> list. Each flag that is ready to archive has a “Ready to archive” indicator in the Flags</strong> list. Click the indicator to begin the archival process.</p> To find all flags that need code removal or are ready to archive, navigate to the Flags</strong> list and open the Filters</strong> menu. Under “Lifecycle,” select Needs code removal</strong> or Ready to archive</strong>. To learn more, read Archiving flags</a>.</p> If you don’t remove and archive flags that no one is using, they can become a form of technical debt. However, do not archive flags solely because of their status. Be sure the flag is no longer in use. To learn more, read Flag statuses and lifecycle stages</a>.</p> You may sometimes see flags on the Flags</strong> list that you have removed from your code, but appear to still be active. To troubleshoot this, read the LaunchDarkly Knowledge Base articles How to investigate removed flags that appear active</a> and Flag removed from code is still showing evaluations</a>.</p> </a>Organizational methods for reducing flag debt</h2> This section discusses processes you can follow within your organization to reduce or eliminate flag debt.</p> </a>Create organization-wide naming conventions</h3> A shared naming convention for your organization’s flags is an effective way to eliminate debt. Flags should have understandable, intuitive names.</p> For example, imagine a flag named FF123_do_not_delete_this_72</code>. When the developer that created the flag leaves the company, the person who takes over their work cannot necessarily tell what that flag is supposed to do. The name of that flag is too obscure to easily determine if the flag is important or not, and taking time to find the flag references in the codebase, determine the results of its variations, and calculate the impact of archiving the flag all seem less urgent than other work.</p> If flags do not have human-readable names, they can become technical debt.</p> To learn more, read Flag conventions</a>.</p> </a>Write useful descriptions</h3> Use descriptions to add more context to the flag. Unlike flag names, you can update descriptions. They can include detailed information, such as the date the flag was last reviewed, the purpose of the flag, and more.</p> Descriptions are fast ways to help other account members learn what a flag does and what its impact is.</p> </a>Minimize flag scope</h3> A flag should have limited scope. Having a flag that controls more than one feature action at a time can be confusing and can make it harder to troubleshoot problems.</p> Imagine the smallest unit of logic needed for the most responsive flag. If there are multiple parts to a feature that have to work together, you can create a main flag with other flags dependent on it.</p> For example, you launch a new dashboard with three widgets. To manage them, create four flags: one flag for each widget, with a dependency on a fourth flag for the main dashboard. In this scenario, if one widget causes problems, you can disable it and still serve the dashboard with the two remaining widgets.</p> </a>Only using flags where necessary</h3> You do not need to use feature flags for every change you make to your codebase. Limit the use of flags in certain situations to help manage your flag debt.</p> We recommend against using flags in the following scenarios:</p> As a replacement for secrets management, or for targeting on secrets or credentials.</li> As a replacement for configuration management. Don’t use feature flags with configuration that is static or rarely changes. Only use flags for this type of configuration if you need an emergency shut-off switch.</li> Don’t use feature flags on configuration that, if disabled, would completely block the application from starting. For example, a database hostname or API URLs.</li> </ul> </li> As a database or file store. Instead, keep variations small and avoid complex JSON payloads where possible. Consider breaking up complex flags into smaller individual flags.</li> For every commit, sprint, or other small change. Flagging very small changes is usually not worth the cost of flag upkeep. Instead, wrap features as a whole.</li> </ul> </a>Mark flags as temporary</h3> When you create or edit a flag, you can indicate whether or not the flag is temporary by selecting the This is a temporary flag</strong> checkbox on the flag’s settings page.</p> You can also filter flags based on whether they are temporary or permanent. This can help you find flags to archive. When someone tries to archive a permanent flag, a warning appears. This can help prevent flags from being archived unnecessarily.</p> When you conduct a flag review, confirm the This is a temporary flag</strong> checkbox is unchecked for every permanent flag.</p> To learn more, read Other flag settings</a>.</p> </a>Use effective tagging conventions</h3> Tags are strings you can attach to any flag within LaunchDarkly. They help you group resources together.</p> You can control the spread of technical debt with tags by including a tag with a sprint designation or deploy date. When you conduct your regularly scheduled reviews, you can search for specific sprints or deploy dates.</p> Tag case sensitivity</p> Tags are case sensitive. For example, searching for Permanent</code> tags and permanent</code> tags will yield different results.</p> </a>Include flags in your workflow’s definition of “done”</h3> Each company and team within an organization may have their own standards for what constitutes “done” on a task or project. Done indicates the project can be removed from the list of current tasks. For example, a team may consider the code for a task to be incomplete until it has passed automated tests.</p> Done means different things for different teams. A feature may be done when it rolls out to 100% of contexts, or when it rolls out to a specific set of contexts. When a feature is fully rolled out, or an experiment is ended, that’s the best time to clean up the flag. When scheduling the work for rolling out a feature, include the flag cleanup work in the schedule. A feature is done when the flag is archived.</p> If the flag you use for a release will convert to a permanent flag, the definition of done should be when the setting on the flag changes to indicate it is permanent. You can make archiving flags part of each sprint or project end. Using this method, you’ll do the work to archive the flag when the context is fresh.</p> To learn more about integrating flag archiving behavior into your feature development processes, read the LaunchDarkly blog article How to use feature flags without technical debt</a>.</p> </a>Plan to remove flags during flag creation</h3> When creating a pull request to add a flag into your code, you can also create a second pull request which removes the flag. This pull request should simply remove the flag code without other changes. This minimizes the number of conflicts to resolve even if, as often happens, the code for the new feature is updated before the rollout is finished.</p> The code may change before you merge the branch, but creating it gives you somewhere to start when you’re ready to clean up the code. The presence of the branch also serves as a reminder to remove the flag when it’s no longer needed.</p> </a>Retire inactive projects</h3> You can identify entire projects that may be inactive by the age and activity level of its flags. If no one has created new flags within the project in the last three months, and it does not contain any active permanent flags, you may be able to delete the project. To learn how, read Delete projects</a>.</p> </a>Receive flag removal alerts in Slack</h3> The LaunchDarkly Slack app can send you notifications when it’s time to remove flags from code. To learn more, read Receive alerts when flags are ready to remove</a>.</p> </a>Methods for reducing flag debt in LaunchDarkly</h2> LaunchDarkly provides several tools to help you reduce flag debt.</p> </a>Use the flag archive checks</h3> On the Flags</strong> list, use the Display</strong> menu to show archive checks for your flags. When archive checks are selected, the Flags</strong> list indicates whether a flag is needs code removal or is ready to archive. You can also use the Filter</strong> menu to filter for flags that need code removal or are ready to archive. To learn more, read Archiving flags</a> and Flag statuses and lifecycle stages</a>.</p> </a>Use the flag health metric</h3> Engineering insights is an Enterprise feature</p> Engineering insights is available to customers on an Enterprise plan. To learn more, read about our pricing</a>. To upgrade your plan, contact Sales</a>.</p> If you use engineering insights, you can use the flag health metric to help reduce flag debt. For most organizations, a lower stale flag percentage is desirable.</p> When you look at flag health in one environment, you might want to decrease your stale flag percentage because most stale flags represent tech debt that you need to clean up or remove.</p> We strongly recommend looking at flag health across environments as well. Differences in flag statuses between environments could indicate a problem. For example, if a flag is “Launched” in all but one environment and “Inactive” in the final environment, maybe you forgot to roll it out. You can use the “Select environments to compare status” feature as an opportunity to double-check your release procedures. To learn more, read Flag health</a>.</p> Here are some strategies to decrease your stale flag percentage:</p> Rolling out flags in all relevant environments</li> Removing or archiving flags when you’re done with them</li> Marking flags permanent, when it’s warranted</li> </ul> Focusing too much on decreasing your stale flag percentage can lead to bad practices in your flag health processes. For example, you can mark a temporary flag as permanent to decrease your stale flag percentage, because only temporary flags can be stale. But most of the time, you should archive a temporary flag when it is no longer needed, not mark it as permanent.</p> Instead, discuss your overall goals for flag health as a team. You can talk through the flag lifecycle and decide on organizational standards for topics including naming conventions, tags, making flags permanent, and deprecating, archiving, and deleting flags.</p> </a>Deprecate, archive, and delete flags</h3> LaunchDarkly provides the options to deprecate, archive, and delete flags. We strongly recommend deprecating or archiving flags rather than deleting them, because an archived flag’s history remains in your LaunchDarkly project. To learn how, read Deprecating, archiving, and deleting flags</a>.</p> If you use engineering insights, you can archive flags directly from the flag health page.</p> Deprecate or archive flags instead of deleting them whenever possible</p> If you delete a flag, LaunchDarkly deletes all references to the flag, including its history. Deleting a flag also means a member could make a new flag with the same key as the old deleted flag. If this happens and the old flag’s key still exists in your codebase, your code could begin referencing the wrong flag. This can have serious and unpredictable effects on your app performance.</p> LaunchDarkly SDKs consider archived flags “gone.” When you select a flag to archive, the panel takes you through the archiving process. LaunchDarkly warns you if you try to archive a flag that is still serving variations, or that is detected in your code through code references.</p> A healthy project has a high ratio of archived to unarchived flags. A general guideline is that any project over three months old should have archived at least one flag. If it has not, you may want to examine your archival practices. An appropriate time-to-archive varies depending on your business needs, but a general best practice is to archive flags quarterly. This means a healthy time-to-archive is in the 90-120 day range.</p> Generally, a project should have fewer deleted flags than archived flags. If you have more deleted flags than archived flags, or if a project has more than ten deleted flags, you may need to review your archiving and deleting practices. You may choose to restrict who can delete flags by assigning them a custom role. To learn more, read Custom roles</a>.</p> Custom roles is an Enterprise feature</p> Custom roles are available to customers on an Enterprise plan. To learn more, read about our pricing</a>. To upgrade your plan, contact Sales</a>.</p> </a>Schedule regular flag reviews</h3> Schedule regular review cycles on a monthly or quarterly basis to identify flags to archive. Some companies dedicate sprints to tackling technical debt. If you do this, include a review of your feature flags, too.</p> Some teams schedule a regular “Flag Cleanup Day.” In preparation, a team member produces a list of flags to be cleaned up. The list is divided up amongst the team. Then, each team member goes through their assigned flags and, for each flag, produces a patch or pull request which removes the flag from the code.</p> In addition to temporary flags, you should also review any permanent flags to determine that they are still necessary. As features change, the need for the flags associated with them can also change.</p> For example, you can filter by flags that you or your team maintain, and by the lifecycle stage</a> of the flag. LaunchDarkly automatically indicates each flag that is “Ready for code removal” or “Ready to archive.” You can save your list filter configurations to return to later, making it easy to regularly check for flags to archive. To learn how, read Save shortcuts to filtered Flags lists</a>.</p> If you use engineering insights, you can also filter and archive flags from the flag health page. The stale Flags</strong> list shows information about flags in a selected environment that we recommend you remove.</p> You can use the search and filter options to refine this list into a different subset of flags:</p> Search by flag key</li> Filter by flag maintainer, tags, and ready to archive or needs review</li> Sort by flag age</li> </ul> You can select additional environments to compare the flag state against. This helps you verify that you can archive the flag without unintended consequences.</p> </a></p> Compare environments.</p> If you choose additional environments, LaunchDarkly performs the checks again and highlights stale flags. To learn more, read Flag health</a>.</p> </a>Use code references to find and remove references to flags</h3> Archiving a flag removes it from the Flags</strong> list and your app’s contexts no longer encounter it.</p> Before you do this, remove the flag from your codebase. Code references let you quickly find where in your source code feature flags are referenced. This simplifies the process of finding code to remove in projects and files.</p> To access code references:</p> Navigate to the Flags</strong> list and find the flag you wish to remove.</li> Click the flag’s name to view the flag’s details.</li> Click the repository name in the “Code references” section of the right sidebar to view the flag’s code references:</li> </ol> </a></p> The “Code references” tab of a feature flag.</p> The flag health metric also automatically verifies whether or not there are code references for your flags.</p> After you remove all code references mentioning that flag from the codebase and rerun the scanning tool, LaunchDarkly creates an extinction event. This event appears as a message on the Code references</strong> tab of the feature flag. To learn more, read About extinction events</a>.</p> </a>Conclusion</h2> In this guide, you learned about:</p> Challenges of technical debt</li> The flag lifecycle</li> Processes and features within LaunchDarkly to help control flag debt</li> </ul> For additional discussion on the lifecycle of a feature flag, read the ebook Effective Feature Management</a>.</p> 减少特性标志的技术债务</h1> 阅读时间：16分钟</h4> 最后编辑：2024年10月15日</h4> </a>概览</h2> 本指南提供了使用LaunchDarkly减少和消除与特性标志相关的技术债务的方法。像所有债务一样，技术债务会随着时间积累，但如果您在需要之前就建立有效的流程，就可以随着时间减轻这些债务。</p> 在本指南中，我们将探讨：</p> 技术债务的挑战</li> 标志的生命周期</li> 命名约定</li> 使用标签</li> 代码引用</li> 弃用、归档和删除标志</li> </ul> 就像特性标志应该是核心工程实践一样，解决技术债务的策略也应该是。LaunchDarkly可以通过自动识别需要代码移除或准备归档的标志来帮助您。</p> </a>先决条件</h2> 要完成本指南，您必须具备以下先决条件：</p> 熟练掌握在LaunchDarkly中创建特性标志</li> 了解您组织的发布流程</li> </ul> </a>概念</h2> 在阅读本指南之前，您应该了解以下概念：</p> </a>技术债务</h3> 技术债务是软件开发中的一个概念，描述了由于未来需要重做的工作而产生的隐含成本，因为短期内采用了有限的解决方案。这通常是因为为了满足交付物或截止日期，必须延迟必要的工作而造成的。</p> 随着这种债务的积累，系统和代码的维护变得更加困难，这可能会影响未来开发的速度和代码库的效率。</p> 技术债务积累的一种方式是未能维护您的特性标志。</p> </a>软件交付生命周期</h3> 软件交付生命周期（SDLC）是软件项目遵循的一个过程。该过程描述了如何开发、维护和修改软件。软件交付周期的阶段包括：</p> 计划</li> 分析</li> 设计</li> 实施</li> 测试和集成</li> 维护</li> </ul> </a>临时和永久标志</h3> 标志要么是临时的，要么是永久的。临时标志有有限的生命周期。一旦标志实现了其业务目的，就将其从代码库中移除。临时标志包括用于发布管理、实验和互操作性测试的标志。</p> 永久标志在功能发布后提供长时间的控制。它们可能会存在整个功能的生命期。永久标志包括用于权利、负载削减、自定义品牌或可访问性的标志。</p> </a>技术债务的挑战</h2> 每个功能都应该有一个标志，但如果不定期归档标志，您可能会积累大量债务。</p> 杂乱无章的代码更难维护和测试。不必要的代码仍然存在，因为没有人记得它为什么存在，并且担心如果移除它会导致问题。未能移除标志会导致代码杂乱无章。</p> 您不仅希望从代码中移除标志的引用，还不希望发送您不需要的标志的评估设置。当您使用像数据导出这样的功能来跟踪您的发布影响时，您的数据库可能会被不必要的事件数据淹没。您不希望传输和存储应该在三个月前归档的标志的数据。</p> 未能移除标志会使您的标志</strong>列表和代码变得杂乱无章。您不能快速找到需要切换的标志。这可能看起来像是一个次要的不便，但如果需要快速切换标志的目标，不得不滚动浏览数百个标志会增加时间。但是，代码杂乱和庞大的标志</strong>列表并不是唯一的挑战。</p> 您还可能面临旧标志评估为无效或不理想状态的风险。当您推出新的更改，如更新的用户界面（UI）时，通常的做法是将当前UI作为默认版本，直到您对新版本有信心。一旦标志为100%的上下文服务了新UI，标志就达到了其生命周期的终点，应该被归档。未能这样做就有回退到不想要的旧UI的风险，如果标志被关闭，或者SDK失败导致使用回退值。</p> 定期测试永久标志的回退值，以确保它们是最新的并提供有效的状态。要了解更多关于回退值的信息，请阅读更改默认标志值</a>。</p> </a>标志生命周期</h2> 标志在其生命周期中可能会经历几个阶段，包括：</p> 活跃</li> 准备代码移除</li> 准备归档</li> 已归档</li> 已弃用</li> 已删除</li> </ul> 生命周期阶段基于所有环境中发生的情况。并非所有标志都会经历所有生命周期阶段。</p> 如果标志是临时标志，并且不再被评估（“非活跃”状态），或者对所有上下文提供相同的变体（“已发布”状态），则标志准备进行代码移除。“非活跃”状态可能意味着您不再运行评估标志的代码。“已发布”状态可能意味着任何新功能的逐步推出已经结束，现在该功能对所有上下文都是活跃的。标志仍然每次运行代码时都被评估，但由于它对每个人都返回相同的变体，因此不再需要。您现在应该从代码中移除标志，然后归档标志，或者将标志转换为永久标志，您可以使用它作为断路器完全禁用该功能。</p> 例如，考虑这个标志：</p> </a></p> 一个状态为“非活跃”且生命周期阶段为“准备归档”的标志。</p> 这个标志的状态是“非活跃”，并且被标记为“准备归档”。没有人使用这个标志。您可以从代码中移除它并归档它。</p> LaunchDarkly通过检查您的所有关键环境</a>中的标志、年龄、状态和是否为先决条件，自动确定标志是否准备归档。您可以从标志</strong>列表中查看准备归档的标志。每个准备归档的标志在标志</strong>列表中都有一个“准备归档”的指示器。单击指示器开始归档过程。</p> 要找到所有需要代码移除或准备归档的标志，请导航到标志</strong>列表并打开筛选器</strong>菜单。在“生命周期”下，选择需要代码移除</strong>或准备归档</strong>。要了解更多信息，请阅读归档标志</a>。</p> 如果您不移除和归档没有人使用的标志，它们可能成为一种技术债务。然而，不要仅因为它们的状态就归档标志。确保标志不再被使用。要了解更多信息，请阅读标志状态和生命周期阶段</a>。</p> 有时您可能会在标志</strong>列表上看到您已经从代码中移除的标志，但它们似乎仍然活跃。要进行故障排除，请阅读LaunchDarkly知识库文章如何调查看起来活跃的已移除标志</a>和代码中已移除的标志仍然显示评估</a>。</p> 编写有用的描述</h3> 使用描述为标志添加更多上下文。与标志名称不同，您可以更新描述。它们可以包括详细的信息，例如标志上次审查的日期、标志的目的等。</p> 描述是帮助其他账户成员快速了解标志功能及其影响的便捷方式。</p> 最小化标志范围</h3> 一个标志应该具有有限的范围。一个标志如果同时控制多个功能动作，可能会造成混淆，并且可能使得问题排查变得更加困难。</p> 想象一下，对于最灵敏的标志所需的最小逻辑单元是什么。如果一个功能有多个部分需要协同工作，您可以创建一个主标志，并让其他标志依赖于它。</p> 例如，您启动了一个带有三个小部件的新仪表板。为了管理它们，创建四个标志：每个小部件一个标志，以及一个依赖于主仪表板的第四个标志。在这种情况下，如果一个小部件出现问题，您可以禁用它，仍然可以用剩下的两个小部件提供仪表板服务。</p> 仅在必要时使用标志</h3> 您不需要对代码库中的每个更改都使用特性标志。在某些情况下限制标志的使用，可以帮助管理您的标志债务。</p> 我们建议不要在以下情况下使用标志：</p> 作为秘密管理的替代品，或用于针对秘密或凭证的目标。</li> 作为配置管理的替代品。不要将特性标志用于静态或很少更改的配置。只有在需要紧急关闭开关时，才使用标志进行此类配置。</li> 不要在禁用后会完全阻止应用程序启动的配置上使用特性标志。例如，数据库主机名或API URL。</li> </ul> </li> 作为数据库或文件存储。相反，保持变体小，并在可能的情况下避免复杂的JSON负载。考虑将复杂的标志分解为更小的单个标志。</li> 对于每次提交、冲刺或其他小更改。标记非常小的更改通常不值得维护标志的成本。相反，将功能作为一个整体进行包装。</li> </ul> 将标志标记为临时</h3> 当您创建或编辑标志时，可以通过在标志的设置页面上选择这是一个临时标志</strong>复选框来指示标志是否为临时标志。</p> 您还可以根据标志是临时的还是永久的来过滤标志。这可以帮助您找到要归档的标志。当有人尝试归档一个永久标志时，会出现警告。这可以防止标志被不必要地归档。</p> 当您进行标志审查时，确认每个永久标志的这是一个临时标志</strong>复选框未被选中。</p> 要了解更多信息，请阅读其他标志设置</a>。</p> 使用有效的标记约定</h3> 标签是您可以附加到LaunchDarkly中任何标志的字符串。它们帮助您将资源分组。</p> 您可以通过包含带有冲刺指定或部署日期的标签来用标签控制技术债务的传播。当您进行定期审查时，可以搜索特定的冲刺或部署日期。</p> 标签大小写敏感</p> 标签是大小写敏感的。例如，搜索Permanent</code>标签和permanent</code>标签将产生不同的结果。</p> 在工作流程的定义中包含标志</h3> 每个公司和组织内的团队可能都有自己的标准，以确定任务或项目何时算作“完成”。完成表示项目可以从当前任务列表中移除。例如，一个团队可能认为，除非任务的代码通过了自动化测试，否则任务的代码不完整。</p> 对于不同的团队，“完成”意味着不同的事情。一个功能可能在它推广到100%的上下文中时算作完成，或者当它推广到特定一组上下文时算作完成。当一个功能完全推出，或者一个实验结束时，那是清理标志的最佳时机。在安排功能推广的工作时，将标志清理工作包含在计划中。当标志被归档时，一个功能就算完成了。</p> 如果您用于发布的旗帜将转换为永久标志，则完成的定义应该是当标志设置更改以表明它是永久的时候。您可以使归档标志成为每个冲刺或项目结束的一部分。使用这种方法，当上下文新鲜时，您将完成归档标志的工作。</p> 要了解更多关于如何将标志归档行为集成到您的功能开发流程中，阅读LaunchDarkly博客文章如何在不产生技术债务的情况下使用特性标志</a>。</p> 在标志创建期间计划移除标志</h3> 当您创建一个拉取请求将标志添加到您的代码时，您也可以创建一个第二个拉取请求来移除该标志。这个拉取请求应该只移除标志代码，而没有其他更改。这最小化了即使通常发生的情况，即新功能代码在发布完成前更新，需要解决的冲突数量。</p> 在您合并分支之前，代码可能会更改，但创建它为您提供了开始清理代码的起点。分支的存在也提醒您在不再需要标志时将其移除。</p> 退役不活跃的项目</h3> 您可以通过标志的年龄和活动水平来识别可能不活跃的整个项目。如果在过去三个月内没有人在项目中创建新的标志，并且它不包含任何活跃的永久标志，您可能可以删除该项目。要了解如何操作，阅读删除项目</a>。</p> 在Slack中接收标志移除提醒</h3> LaunchDarkly Slack应用程序可以在您需要从代码中移除标志时发送通知。要了解更多信息，请阅读当标志准备好移除时接收提醒</a>。</p> 在LaunchDarkly中减少标志债务的方法</h2> LaunchDarkly提供了几种工具，可以帮助您减少标志债务。</p> 使用标志归档检查</h3> 在标志</strong>列表上，使用显示</strong>菜单显示标志的归档检查。当选择归档检查时，标志</strong>列表会指示标志是否需要代码移除或准备归档。您也可以使用筛选器</strong>菜单筛选需要代码移除或准备归档的标志。要了解更多信息，请阅读归档标志</a>和标志状态和生命周期阶段</a>。</p> 使用标志健康度量</h3> 工程洞察是企业版功能</p> 工程洞察适用于企业版计划的客户。要了解更多信息，请阅读我们的定价信息</a>。要升级您的计划，请联系销售</a>。</p> 如果您使用工程洞察，您可以使用标志健康度量来帮助减少标志债务。对于大多数组织来说，较低的陈旧标志百分比是可取的。</p> 当您在一个环境中查看标志健康度时，您可能希望减少您的陈旧标志百分比，因为大多数陈旧标志代表您需要清理或移除的技术债务。</p> 我们还强烈建议查看跨环境的标志健康度。不同环境之间标志状态的差异可能表明存在问题。例如，如果一个标志在所有环境中都处于“已发布”状态，而在最后一个环境中处于“非活跃”状态，可能您忘记了将其推出。您可以使用“选择环境比较状态”功能作为双重检查您的发布程序的机会。要了解更多信息，请阅读标志健康度</a>。</p> 以下是一些减少您的陈旧标志百分比的策略：</p> 在所有相关环境中推出标志</li> 当您完成标志时，将其移除或归档</li> 在适当的情况下，将标志标记为永久性</li> </ul> 过分关注减少您的陈旧标志百分比可能会导致标志健康流程中的不良实践。例如，您可以将临时标志标记为永久性，以减少您的陈旧标志百分比，因为只有临时标志可以变得陈旧。但大多数情况下，当不再需要临时标志时，您应该将其归档，而不是将其标记为永久性。</p> 相反，作为团队讨论您的标志健康总体目标。您可以讨论标志的生命周期，并为命名约定、标签、使标志永久化以及弃用、归档和删除标志等主题确定组织标准。</p> 弃用、归档和删除标志</h3> LaunchDarkly提供了弃用、归档和删除标志的选项。我们强烈建议尽可能弃用或归档标志，而不是直接删除它们，因为归档标志的历史记录会保留在您的LaunchDarkly项目中。要了解如何操作，请阅读弃用、归档和删除标志</a>。</p> 如果您使用工程洞察功能，您可以直接从标志健康页面归档标志。</p> 尽可能弃用或归档标志，而不是删除它们。</p> 如果您删除了一个标志，LaunchDarkly会删除所有对该标志的引用，包括其历史记录。删除标志还意味着其他成员可以创建一个与已删除标志具有相同键的新标志。如果发生这种情况，并且旧标志的键仍然存在于您的代码库中，您的代码可能会开始引用错误的旗帜。这可能会对您的应用程序性能产生严重且不可预测的影响。</p> LaunchDarkly SDK将归档标志视为“已删除”。当您选择归档一个标志时，面板会带您完成归档过程。如果您尝试归档一个仍在提供变体的标志，或者通过代码引用在代码中检测到的标志，LaunchDarkly会警告您。</p> 一个健康的项目应该有很高比例的已归档标志与未归档标志。一般准则是，任何超过三个月的项目至少应该归档一个标志。如果没有，您可能需要检查您的归档实践。适当的归档时间取决于您的业务需求，但一般最佳实践是每季度归档标志。这意味着健康的归档时间应在90-120天范围内。</p> 通常，项目中被删除的标志数量应该少于被归档的标志数量。如果您有更多被删除的标志而不是被归档的标志，或者如果一个项目有超过十个被删除的标志，您可能需要审查您的归档和删除实践。您可以选择通过分配自定义角色来限制谁可以删除标志。要了解更多信息，请阅读自定义角色</a>。</p> 自定义角色是企业版功能</p> 自定义角色适用于企业版计划的客户。要了解更多信息，请阅读我们的定价信息</a>。要升级您的计划，请联系销售</a>。</p> 定期安排标志审查</h3> 定期安排每月或季度的标志审查周期以识别要归档的标志。一些公司会专门安排冲刺来处理技术债务。如果您这样做，请也包括对您的特性标志的审查。</p> 一些团队会定期安排一个“标志清理日”。准备时，团队成员会制作一个要清理的标志列表。然后将列表分配给团队成员。之后，每个团队成员会处理他们分配到的标志，并为每个标志产生一个补丁或拉取请求，以从代码中移除该标志。</p> 除了临时标志外，您还应该审查任何永久标志，以确定它们是否仍然必要。随着功能的变更，与之相关的标志的需求也可能发生变化。</p> 例如，您可以根据您或您的团队维护的标志以及标志的生命周期阶段</a>进行过滤。LaunchDarkly自动标记每个“准备进行代码移除”或“准备归档”的标志。您可以保存您的列表过滤配置以便以后返回，使定期检查要归档的标志变得容易。要了解如何操作，请阅读保存过滤标志列表的快捷方式</a>。</p> 如果您使用工程洞察功能，您还可以从标志健康页面过滤和归档标志。陈旧的标志</strong>列表显示了我们建议您移除的标志在选定环境中的信息。</p> 您可以使用搜索和过滤选项将此列表细化为不同的标志子集：</p> 按标志键搜索</li> 按标志维护者、标签和准备归档或需要审查进行过滤</li> 按标志年龄排序</li> </ul> 您可以选择额外的环境来比较标志状态。这有助于您验证您可以归档标志而不会产生意外后果。</p> </a></p> 比较环境。</p> 如果您选择了额外的环境，LaunchDarkly会再次执行检查并突出显示陈旧的标志。要了解更多信息，请阅读标志健康</a>。</p> 使用代码引用查找和移除标志引用</h3> 归档一个标志会将其从标志</strong>列表中移除，您的应用程序上下文不再遇到它。</p> 在这样做之前，请从您的代码库中移除该标志。代码引用让您可以快速找到源代码中引用了哪些功能标志。这简化了在项目和文件中查找要移除的代码的过程。</p> 要访问代码引用：</p> 导航到标志</strong>列表并找到您希望移除的标志。</li> 单击标志的名称以查看标志的详细信息。</li> 单击右侧边栏中“代码引用”部分的存储库名称，以查看标志的代码引用：</li> </ol> </a></p> 功能标志的“代码引用”标签页。</p> 标志健康度量也会自动验证您的标志是否有代码引用。</p> 在您从代码库中移除所有提及该标志的代码引用并重新运行扫描工具后，LaunchDarkly会创建一个灭绝事件。此事件出现在功能标志的代码引用</strong>标签页上的消息中。要了解更多信息，请阅读关于灭绝事件</a>。</p> 结论</h2> 在本指南中，您了解到：</p> 技术债务的挑战</li> 标志的生命周期</li> LaunchDarkly内部帮助控制标志债务的流程和功能</li> </ul> 有关功能标志生命周期的更多讨论，请阅读电子书有效的功能管理</a>。</p> 代码分支管理 2024-09-18T00:00:00+00:00 拆分为两套代码所存在的问题：</h1> 使用不同分支后，大型修改的合并将变得极为困难，不论是从上游合并到下游，还是下游合并到上游，都将成为一个耗时巨大的工程，以轻共享代码合并上游为例，历时3个多月，经历过大量测试，仍然出现风险不可控。如果只是禁绝了从下游合并到上游的可能，下游的客户也一样需要承担上游合并到下游所带来的功能异常风险，及下游代码丢失的风险，该风险从宏观和微观层面，都与下游合并至上游一致。</p> 分析目前工作特性</h1> 需求差异</h2> 在没有强一致性的标准下，toB产品必然存在由于管理制度不同而导致的需求差异情况，那么针对某个企业的特异需求，如何考虑，转换成一个可以通用的配置性需求，是对大客户产品设计的一个必定要求。如果转换成了通用性的配置性需求，那么就可以认为是一个标准化的产品需求，那需要解决的问题就是由于交付压力而导致的交付时间问题，而交付压力在研发过程中就转换成为了团队资源差异，最终转变为代码差异。</p> 三种服务扩展方式</h2> 对于一个已有服务的扩展应该分为三种类型：</p> openapi式扩展</li> 服务覆盖式扩展</li> 代码式扩展</li> </ol> 在目前的实践阶段，由于微服务化程度不够，主要的扩展方式为1、3两种，其中openapi式扩展由二开团队负责，代码式扩展由大客团队负责。</p> 在深度微服务化后，可以增加一种服务覆盖式的扩展手段，以保证上游代码不变的情况下，下游代码实现新的接口，以新的逻辑提供服务，并不需要阻止有共性的服务，而可以由服务调用方进行逐渐的优选，详见亚马逊AwayTeams模式。</p> 由于交付时间压力的存在，所以代码式扩展不可能被完全禁绝，所以代码质量管理成为目前最大的管理症结，例如之前提出的，责任田内代码被其他团队修改，导致最终的bug权责不清问题。</p> 参考管理实践</h2> 对于大型团队的代码管理，参照了大型公司谷歌、亚马逊、脸书以及大型开源项目如Linux基金会的管理方案。</p> 谷歌工程实践 | 谷歌工程实践</a></p> Amazon Away Teams架构剖析/解密：AWS的工程师如何开发和维护他们的内部技术</a></p> [转]facebook是如何管理代码的_trace的技术备忘专栏-CSDN博客</a></p> How Facebook Ships Code</a></p> Participating in Open Source Communities - Linux Foundation</a></p> 提取的共性：</h2> Code Owner</p> Code Review</p> 二开现状更类似于开源软件项目的上下游概念：</p> 主产品作为上游。</p> 二开部署代码作为下游，如果每个客户都存在只属于该客户的代码增量，需要投入大量的资源来保证下游代码稳定，如果所有大客户使用同一套代码作为下游，则与上游并没有根本区别。</p> 优化方案</h1> 优化代码管理思想：</p> 来自于其他团队的代码贡献不可避免，只需通过code review的方式避免低质量代码合并，下游贡献的高质量代码是对责任田能力的优质补充。</p> 如果沿用现有组织机构，提升上下游意识，保证“上游优先”可以解决代码差异问题，通过CodeReview来提高其他团队修改代码导致的质量问题。</p> 开源软件项目的“上游优先”解惑 - 开源之道 (opensourceway.community)</a></p> Vim使用小技巧 2024-08-28T00:00:00+00:00 如何键入真正的Tab字符？</h1> 如果你想要在 Vim 中输入真正的 Tab 字符，你可以在插入模式下按 Ctrl-V，然后按 Tab。这将插入一个真正的 Tab 字符，而不是空格。</p> 注释代码？</h1> 快捷注释， V gc</code></p> 如何缩进？</h1> 在 Neovim 中，您可以使用以下方法进行代码缩进：</p> 自动缩进：在插入模式下，当您按下回车键时，Neovim 会自动缩进新的一行。这是由 autoindent</code> 选项控制的，通常默认开启。</p> </li> 手动缩进：在普通模式下，您可以使用 >></code> 来缩进当前行，使用 <<</code> 来取消当前行的缩进。</p> </li> 可视模式缩进：在可视模式下（按 v</code> 进入），您可以选择多行，然后使用 ></code> 或 <</code> 来增加或减少选定行的缩进。</p> </li> 使用 =</code> 自动调整缩进：在普通模式下，您可以使用 ==</code> 来自动调整当前行的缩进，或者在可视模式下选择多行，然后按 =</code> 来自动调整选定行的缩进。</p> </li> </ol> 注意：缩进的宽度是由 tabstop</code>、shiftwidth</code> 和 expandtab</code> 这几个选项控制的。您可以在 Neovim 的配置文件中设置这些选项，例如：</p> set</span> tabstop=</span>4 </span>set</span> shiftwidth=</span>4 </span>set expandtab </span></code></pre> 以上设置将使得缩进为 4 个空格宽，并且使用空格代替制表符进行缩进。</p> 如何format代码？</h1> 在 Neovim 中，您可以使用内置的 =</code> 命令来格式化代码。以下是一些常见的使用方式：</p> 格式化整个文件：在普通模式下，使用 gg=G</code> 命令。gg</code> 将光标移动到文件的开始，=</code> 是格式化命令，G</code> 将光标移动到文件的结束。</p> </li> 格式化当前行：在普通模式下，使用 ==</code> 命令。</p> </li> 格式化选定的文本：在可视模式下（按 v</code> 进入），选择您想要格式化的文本，然后按 =</code>。</p> </li> </ol> 请注意，这些命令的效果取决于 Neovim 的缩进设置和当前文件类型的文件类型插件。</p> 对于更复杂的代码格式化，例如按照特定的编码风格进行格式化，您可能需要安装额外的插件。例如，对于 Python，您可以使用 black</code> 或 yapf</code> 插件；对于 JavaScript，您可以使用 prettier</code> 插件。安装这些插件后，您可以配置 Neovim 在保存文件时自动格式化代码，或者配置一个快捷键来手动格式化代码。</p> 如何粘贴clipboard中的内容？</h1> 在 Neovim 中，您可以使用以下命令来粘贴剪贴板的内容：</p> 在普通模式下，使用命令 "+p</code> 来粘贴剪贴板的内容。</p> 这里的 "+</code> 是指代系统剪贴板，p</code> 是粘贴命令。</p> 如果您想在插入模式下粘贴剪贴板的内容，可以先按 Ctrl + o</code> 进入插入-普通模式，然后再使用 "+p</code> 命令。</p> 请注意，这需要您的 Neovim 支持剪贴板功能。您可以通过命令 :checkhealth</code> 来检查 Neovim 的剪贴板支持情况。如果看到 Clipboard (optional): OK</code>，那么表示剪贴板功能可用。如果不可用，您可能需要安装额外的软件（如 xclip</code> 或 xsel</code>）来提供剪贴板支持。</p> 如何重新加载配置文件？</h1> 在 Neovim 中，您可以使用以下命令重新加载配置文件：</p> :luafile ~</span>/.config/</span>nvim/init</span>.</span>lua </span></code></pre> 如何修改工作目录</h1> :cd ~/path </span></code></pre> 如何在termux中的vim里输入中文？</h1> 有时termux的终端无法输入中文，可以通过以下方法解决：将termux最下面的快捷栏向左滑动，就会进入一个文本输入模式，此时可以激活输入法，切换到中文输入法后，再向右滑动快捷栏，就可以在vim中直接输入中文了。</p> NvChad 2024-08-26T00:00:00+00:00 </p> Ctrl+n </span>打开/关闭 NvimTree </span></code></pre> Istio Error Flag 2024-08-21T00:00:00+00:00 HTTP and TCP</p> Long name</th> Short name</th> Description</th></tr></thead> NoHealthyUpstream</strong></td> UH</strong></td> No healthy upstream hosts in upstream cluster in addition to 503 response code.</td></tr> UpstreamConnectionFailure</strong></td> UF</strong></td> Upstream connection failure in addition to 503 response code.</td></tr> UpstreamOverflow</strong></td> UO</strong></td> Upstream overflow (circuit breaking</a>) in addition to 503 response code.</td></tr> NoRouteFound</strong></td> NR</strong></td> No route configured</a> for a given request in addition to 404 response code or no matching filter chain for a downstream connection.</td></tr> UpstreamRetryLimitExceeded</strong></td> URX</strong></td> The request was rejected because the upstream retry limit (HTTP)</a> or maximum connect attempts (TCP)</a> was reached.</td></tr> NoClusterFound</strong></td> NC</strong></td> Upstream cluster not found.</td></tr> DurationTimeout</strong></td> DT</strong></td> When a request or connection exceeded max_connection_duration</a> or max_downstream_connection_duration</a>.</td></tr> </tbody></table> HTTP only</p> Long name</th> Short name</th> Description</th></tr></thead> DownstreamConnectionTermination</strong></td> DC</strong></td> Downstream connection termination.</td></tr> FailedLocalHealthCheck</strong></td> LH</strong></td> Local service failed health check request</a> in addition to 503 response code.</td></tr> UpstreamRequestTimeout</strong></td> UT</strong></td> Upstream request timeout in addition to 504 response code.</td></tr> LocalReset</strong></td> LR</strong></td> Connection local reset in addition to 503 response code.</td></tr> UpstreamRemoteReset</strong></td> UR</strong></td> Upstream remote reset in addition to 503 response code.</td></tr> UpstreamConnectionTermination</strong></td> UC</strong></td> Upstream connection termination in addition to 503 response code.</td></tr> DelayInjected</strong></td> DI</strong></td> The request processing was delayed for a period specified via fault injection</a>.</td></tr> FaultInjected</strong></td> FI</strong></td> The request was aborted with a response code specified via fault injection</a>.</td></tr> RateLimited</strong></td> RL</strong></td> The request was ratelimited locally by the HTTP rate limit filter</a> in addition to 429 response code.</td></tr> UnauthorizedExternalService</strong></td> UAEX</strong></td> The request was denied by the external authorization service.</td></tr> RateLimitServiceError</strong></td> RLSE</strong></td> The request was rejected because there was an error in rate limit service.</td></tr> InvalidEnvoyRequestHeaders</strong></td> IH</strong></td> The request was rejected because it set an invalid value for a strictly-checked header</a> in addition to 400 response code.</td></tr> StreamIdleTimeout</strong></td> SI</strong></td> Stream idle timeout in addition to 408 or 504 response code.</td></tr> DownstreamProtocolError</strong></td> DPE</strong></td> The downstream request had an HTTP protocol error.</td></tr> UpstreamProtocolError</strong></td> UPE</strong></td> The upstream response had an HTTP protocol error.</td></tr> UpstreamMaxStreamDurationReached</strong></td> UMSDR</strong></td> The upstream request reached max stream duration.</td></tr> OverloadManagerTerminated</strong></td> OM</strong></td> Overload Manager terminated the request.</td></tr> DnsResolutionFailed</strong></td> DF</strong></td> The request was terminated due to DNS resolution failure.</td></tr> DropOverload</strong></td> DO</strong></td> The request was terminated in addition to 503 response code due to drop_overloads</a>.</td></tr> </tbody></table> 明史 - 世宗 2024-07-31T00:00:00+00:00 世宗一</h1> 世宗钦天履道英毅神圣宣文广武洪仁大孝肃皇帝，讳厚熜，宪宗孙也。父兴献王祐芫，国安陆，正德十四年薨。帝年十有三，以世子理国事。十六年三月辛酉，未除服，特命袭封。丙寅，武宗崩，无嗣。慈寿皇太后与大学士杨廷和定策，遣太监谷大用、韦彬、张锦，大学士梁储，定国公徐光祚，驸马都尉崔元，礼部尚书毛澄，以遗诏迎。王于兴邸。夏四月癸未，发安陆。癸卯，至京师，止于郊外。礼官具仪，请如皇太子即位礼。王顾长史袁宗皋曰：“遗诏以我嗣皇帝位，非皇子也。”大学士杨廷和等请如礼臣所具仪，由东安门入居文华殿，择日登极，不允。会皇太后趣群臣上笺劝进，乃即郊外受笺。是日日中，入自大明门，遣官告宗庙社稷，谒大行皇帝几筵，朝皇太后。出御奉天殿，即皇帝位。以明年为嘉靖元年，大赦天下。恤录正德中言事罪废诸臣。赐天下明年田租之半，自正德十五年以前逋赋尽免之。丙午，遣使奉迎母妃蒋氏。召费宏复入阁。戊申，命礼臣集议兴献王封号。五月乙卯，罢大理银矿。丙辰，梁储致仕。壬戌，吏部侍郎袁宗皋为礼部尚书兼文渊阁大学士，预机务。壬申，钱宁伏诛。戊子，江彬伏诛。乙未，纵内苑禽兽，令天下毋得进献。丁酉，革锦衣卫冒滥军校三万余人。戊戌，振江西灾。壬寅，革传升官。癸卯，振辽东饥。秋七月壬子，进士张璁言继统不继嗣，请尊崇所生，立兴献王庙于京师。初，礼臣议考孝宗改称兴献王皇叔父，援宋程颐议濮王礼以进，不允。至是下璁奏，命廷臣集议，杨廷和等抗疏力争，皆不听。癸丑，命自今亲丧不得夺情，著为令。丁巳，小王子犯庄浪，指挥刘爵御却之。丙子，革锦衣卫所及监局寺厂司库、旗校、军士、匠役投充新设者，凡十四万八千余人。丁丑，宁津盗起，德平知县龚谅死之。九月乙卯，袁宗皋卒。庚午，葬毅皇帝于康陵。冬十月己卯朔，追尊父兴献王为兴献帝，祖母宪宗贵妃邵氏为皇太后，母妃为兴献后。壬午，兴献后至自安陆。十一月庚戌，振江西灾。丁巳，录平宸濠功，封王守仁新建伯。甲戌，乾清宫成。罢广西贡香。谕各镇巡守备官，凡额外之征悉罢之。嘉靖元年春正月癸丑，享太庙。己未，大祀天地于南郊。清宁宫后殿灾，命称孝宗皇考慈寿皇太后圣母，兴献帝后为本生父母。己巳，甘州兵乱，杀巡抚都御史许铭。二月己卯，耕耤田。三月辛亥，弗提卫献生豹，却之。甲寅，释奠于先师孔子。丁巳，上慈寿皇太后尊号曰昭圣慈寿皇太后，武宗皇后曰庄肃皇后。戊午，上皇太后尊号曰寿安皇太后，兴献后曰兴国太后。夏四月壬辰，命各边巡按御史三年一阅军马器械。秋七月己酉，以南畿、浙江、江西、湖广、四川旱，诏抚按官讲求荒政。九月辛未，立皇后陈氏。冬十月辛卯，振南畿、湖广、江西、广西灾，免税粮有差。壬辰，以灾伤敕群臣修省。十一月庚申，寿安皇太后崩。十二月戊寅，振陜西被寇及山东矿贼流劫者。是年，琉球入贡。二年春正月乙卯，大祀天地于南郊。丁卯，小王子犯沙河堡，总兵官杭雄战却之。二月癸未，振辽东饥。壬辰，总督军务右都御史俞谏、总兵官鲁纲讨平河南、山东贼。三月乙巳，俺答寇大同。甲寅，武宗神主祔太庙。戊午，赐姚涞等进士及第、出身有差。夏四月壬申，以灾异敕群臣修省。癸未，以宋朱熹裔孙墅为五经博士。癸巳，命两京三品以上及抚、按官举堪任守令者。五月庚午，小王子犯密云石塘岭，杀指挥使殷隆。六月癸丑，以灾伤免嘉靖元年天下税粮之半。秋八月辛酉，小王子犯丁字堡，都指挥王纲战死。冬十一月丁卯，免南畿被灾税粮。己丑，振河南饥。是年，撒马儿罕、土鲁番、天方入贡。三年春正月丙寅朔，两畿、河南、山东、陜西同时地震。丁丑，大祀天地于南郊。丙戌，南京刑部主事桂萼请改称孝宗皇伯考，下廷臣议。是月，朵颜入寇。二月丙午，杨廷和致仕。庚戌，南京地震。三月壬申，振淮、扬饥。辛巳，振河南饥。夏四月己酉，上昭圣皇太后尊号曰昭圣康惠慈寿皇太后。庚戌，上兴国太后尊号曰本生圣母章圣皇太后。癸丑，追尊兴献帝为本生皇考恭穆献皇帝，大赦。辛酉，编修邹守益请罢兴献帝称考立庙，下锦衣卫狱。五月乙丑，蒋冕致仕。修撰吕楠言大礼未正，下锦衣卫狱。丁丑，遣使迎献皇帝神主于安陆。己卯，吏部尚书石宝兼文渊阁大学士，预机务。六月，御史段续、陈相请正席书、桂萼罪，吏部员外郎薛蕙上为人后解，鸿胪少卿胡侍言张璁等议礼之失，俱下狱。秋七月乙亥，更定章圣皇太后尊号，去本生之称。戊寅，廷臣伏阙固争，下员外郎马理等一百三十四人锦衣卫狱。癸未，杖马理等于廷，死者十有六人。甲申，奉安献皇帝神主于观德殿。己丑，毛纪致仕。辛卯，杖修撰杨慎，检讨王元正，给事中刘济、安磐、张汉卿、张原，御史王时柯于廷，原死，慎等戍谪有差。是月，免南畿、河南被灾税粮。八月癸巳，大同兵变，杀巡抚都御史张文锦。乙卯，吏部侍郎贾咏为礼部尚书兼文渊阁大学士，预机务。九月丙寅，定称孝宗为皇伯考，昭圣皇太后为皇伯母，献皇帝为皇考，章圣皇太后为圣母。丙子，诏天下。丙戌，土鲁番入寇，围肃州，兵部尚书金献民总制军务，署都督佥事杭雄充总兵官，太监张忠提督军务，御之。冬十月己卯，户部侍郎胡瓒提督宣、大军务，都督鲁纲充总兵官，讨大同叛卒。十二月壬子，甘、凉寇退，召金献民还。戊午，起致仕大学士杨一清为兵部尚书，总制陜西三边军务。是年，琉球入贡。鲁迷国贡狮子、犀牛。四年春正月丙寅，西海卜儿孩犯甘肃，总兵官姜奭击败之。辛未，大祀天地于南郊。二月乙卯，禁淹狱囚。三月壬午，仁寿宫灾。夏五月甲戌，赐庐州知府龙诰官秩。诏天下仿诰备荒振济法。庚辰，作世庙祀献皇帝。八月戊子，作仁寿宫。冬十月丁亥，作玉德殿，景福、安喜二宫。十二月辛丑，大礼集议成，颁示天下。闰月乙卯朔，日有食之。乙亥，振辽东灾。是年，天方入贡。五年春正月乙未，大祀天地于南郊。二月甲寅，命道士邵元节为真人。庚辰，免山西被灾税粮。壬午，振京师饥。三月辛丑，赐龚用卿等进士及第、出身有差。丁未，定有司久任法。夏五月庚子，杨一清复入阁。秋七月庚寅，免四川被灾税粮。八月丙寅，振湖广饥。九月己亥，章圣皇太后有事于世庙。冬十月辛亥朔，亲享如太庙礼。壬子，振南畿、浙江灾，免税粮物料。庚午，颁御制敬一箴于学宫。是年，暹罗入贡。六年春正月癸未，命群臣陈民间利病。己丑，大祀天地于南郊。二月辛亥，小王子犯宣府，参将王经战死。癸亥，费宏、石宝致仕。庚午，召谢迁复入阁。三月庚辰，寇复犯宣府，参将关山战死。甲午，礼部侍郎翟銮为吏部侍郎兼翰林学士，入阁预机务。夏四月己巳，免广西被灾税粮。五月丁丑朔，日有食之。丁亥，前南京兵部尚书王守仁兼左都御史，总制两广、江西、湖广军务，讨田州叛蛮。秋八月庚戌，以议李福达狱，下刑部尚书颜颐寿、左都御史聂贤、大理寺卿汤沐等于锦衣卫狱，侍郎桂萼、张璁，少詹事方献夫署三法司，杂治之。总制尚书王宪击败小王子于石旧墩。癸亥，贾咏致仕。庚午，振湖广水灾。九月己卯，免江西、河南、山西被灾秋粮。壬午，颁钦明大狱录于天下。冬十月戊申，兵部侍郎张璁为礼部尚书兼文渊阁大学士，预机务。是年，鲁迷入贡。七年春正月癸未，考核天下巡抚官。丙戌，大祀天地于南郊。三月戊寅，谢迁致仕。癸巳，右都御史伍文定为兵部尚书提督军务，侍郎梁材督理粮储，讨云南叛蛮。夏四月甲寅，甘露降，告于郊庙。六月辛丑，明伦大典成，颁示天下。癸卯，定议礼诸臣罪，追削杨廷和等籍。丁卯，云南蛮平。秋七月己卯，追尊孝惠皇太后为太皇太后，恭穆献皇帝为恭睿渊仁宽穆纯圣献皇帝。辛巳，尊章圣皇太后为章圣慈仁皇太后。戊子，诏天下。八月壬子，免河南被灾税粮。九月甲戌，王守仁讨广西蛮，悉平之。壬午，振嘉兴、湖州灾。冬十月丁未，皇后崩。十一月丙寅，立顺妃张氏为皇后。十二月丙子，小王子犯大同，指挥赵源战死。是年，琉球入贡。八年春正月己亥，振山西灾。庚戌，大祀天地于南郊。二月癸酉，吏部尚书桂萼兼武英殿大学士，预机务。丁丑，振襄阳饥。甲申，旱，躬祷于南郊。乙酉，祷于社稷。三月丙申，葬悼灵皇后。戊戌，振河南饥。甲寅，赐罗洪先等进士及第、出身有差。秋七月甲午，以议狱不当，下郎中魏应召等于狱，右都御史熊浃削籍。八月丙子，张璁、桂萼罢。壬午，始亲祭山川，著为令。九月癸巳，召张璁复入阁。癸丑，杨一清罢。是月，免两畿、河南被灾税粮。振江西、湖广饥。冬十月癸亥朔，日有食之。己巳，除外戚世封，著为令。十一月庚子，召桂萼复入阁。甲辰，振浙江灾。戊申，祷雪。己酉，雪。丁巳，亲诣郊坛告谢，百官表贺。是年，天方、撒马儿罕、土鲁番入贡。九年春正月丁酉，大祀天地于南郊。丙午，作先蚕坛于北郊。丁巳，振山西饥。二月戊辰，耕耤田。乙亥，振京师饥。丁丑，禁官民服舍器用逾制。三月丁巳，皇后亲蚕于北郊。夏四月丙戌，振延绥饥。五月己亥，更建四郊。六月癸亥，立曲阜孔、颜、孟三氏学。八月壬午，免江西被灾税粮。九月壬辰，罢云南镇守中官。乙未，免南畿被灾秋粮。冬十一月辛丑，更正孔庙祀典，定孔子谥号曰至圣先师孔子。己酉，祀昊天上帝于南郊，礼成大赦。是年，琉球入贡。十年春正月辛卯，祈谷于大祀殿，奉太祖、太宗配。甲午，更定庙祀，奉德祖于祧庙。乙巳，桂萼致仕。二月甲戌，免庐、凤、淮、扬被灾秋粮。壬申，赐张璁名孚敬。三月戊申，罢四川分守中官。夏四月丁巳，皇后亲蚕于西苑。甲子，禘于太庙。五月壬子，祀皇地祇于方泽。闰六月己丑，罢浙江、湖广、福建、两广及独石、万全、永宁镇守中官。秋七月癸丑，侍郎叶相振陜西饥。戊午，张孚敬罢。辛巳，郑王厚烷献白雀，荐之宗庙。八月辛丑，改安陆州曰承天府。九月乙丑，西苑宫殿成，设成祖位致祭，宴群臣。丙寅，礼部尚书李时兼文渊阁大学士，预机务。壬申，幸西苑，御无逸殿，命李时、翟銮进讲，宴儒臣于豳风亭。冬十一月甲寅，祀天于南郊。戊辰，免陜西被灾秋粮。丁丑，召张孚敬复入阁。十二月戊子，御史喻希礼、石金因修醮请宥议礼诸臣罪，下锦衣卫狱。十一年春正月辛未，祈谷于圜丘，始命武定侯郭勋摄事。二月戊戌，免湖广被灾税粮。三月戊辰，赐林大钦等进士及第、出身有差。夏四月辛卯，续封常遇春、李文忠、邓愈、汤和后为侯。五月丙子，前吏部尚书方献夫兼武英殿大学士，预机务。六月壬午，免畿内被灾秋粮。甲申，续封刘基后诚意伯。秋七月戊辰，免南畿被灾夏税。八月戊子，以星变敕群臣修省。辛丑，张孚敬罢。九月丁巳，振陜西饥。冬十月甲申，编修杨名以灾异陈言，下狱谪戍。是月，免山东被灾税粮，振山西饥。十一月甲寅，四川巡抚都御史宋沧献白兔，群臣表贺。庚申，祀天于南郊。十二月己亥，免畿内被灾税粮。是年，琉球、哈密、土鲁番、天方、撒马儿罕入贡。十二年春正月丙午，河南巡抚都御史吴山献白鹿，群臣表贺。自后，诸瑞异表贺以为常。丙辰，召张孚敬复入阁。是月，免浙江、河南被灾税粮。二月乙酉，振云南饥。三月丙辰，释奠于先师孔子。秋八月乙未，以皇子生诏赦天下。九月庚戌，广东巢贼乱，提督侍郎陶谐讨平之。冬十月乙亥，大同兵乱，杀总兵官李瑾，代王奔宣府。丙子，下建昌侯张延龄于狱。十一月己亥，振辽东灾。癸丑，翟銮以忧去。十二月己卯，吉囊犯宁夏，总兵官王效、副总兵梁震击败之。是年，土鲁番天方入贡。十三年春正月癸卯，废皇后张氏。壬子，立德妃方氏为皇后。二月己丑，总督宣大侍郎张瓒抚定大同乱卒。辛卯，代王返国。三月壬申，振大同被兵者。乙酉，吉囊犯响水堡，参将任杰击败之。夏四月己酉，方献夫致仕。六月甲子，南京太庙灾。秋八月壬子，寇犯花马池，梁震御却之。冬十一月庚午，祀天于南郊。是年，琉球入贡。十四年春正月壬申，罢督理仓场中官。丙戌，庄肃皇后崩。二月己亥，作九庙。丁未，禁冠服非制。三月戊子，葬孝静皇后于康陵。己丑，辽东军乱，执都御史吕经。夏四月甲午，张孚敬致仕，召费宏复入阁。丙申，赐韩应龙等进士及第、出身有差。丙午，广宁兵乱。六月，吉囊犯大同，总兵官鲁纲御却之。秋七月甲申，广宁乱卒平。八月乙巳，诏九卿会推巡抚官，著为令。冬十月戊申，费宏卒。十一月乙亥，祀天于南郊。是年，乌斯藏入贡。十五年春二月癸巳，振湖广灾。三月丙子，奉章圣皇太后如天寿山谒陵，免昌平今年税粮三之二，赐高年粟帛。癸未，谒恭让章皇后、景皇帝陵。是日还宫。夏四月癸巳，诏建山陵。癸卯，诣七陵祭告。癸丑，还宫。是月，吉囊犯甘、凉，总兵官姜奭击败之。秋九月庚午，如天寿山。丁丑，还宫。是秋，吉囊犯延绥，官军四战皆败之。冬十月己亥，更定世庙为献皇帝庙。戊申，如天寿山。壬子，还宫。十一月戊午，以皇长子生，诏赦天下。辛巳，祀天于南郊。十二月辛卯，九庙成。闰月癸亥，以定庙制，加上两宫皇太后徽号，诏赦天下。乙丑，礼部尚书夏言兼武英殿大学士，预机务。丙寅，享九庙。是年，免山西、山东被灾税粮。琉球、乌斯藏入贡。十六年春二月壬子，安南黎宁遣使告莫登庸之难。癸酉，如天寿山。三月甲申，还宫。丙午，幸大峪山视寿陵。夏四月癸丑，还宫。六月癸酉，吉囊寇宣府，指挥赵镗战死。秋八月，复寇宣府，杀参将张国辅。冬十一月，故昌国公张鹤龄下狱，瘐死。是年，土鲁番、天方、撒马儿罕入贡。十七年春二月戊辰，如天寿山。壬申，还宫。三月壬辰，赐茅瓒等进士及第、出身有差。辛丑，咸宁侯仇鸾为征夷副将军，充总兵官，兵部尚书毛伯温参赞军务，讨安南莫登庸。夏四月庚戌，如天寿山。甲寅，还宫。戊午，罢安南师。甲子，祷雨于郊坛。戊辰，雨。六月，寇犯宣府，都指挥周冕战死。丙辰，定明堂大飨礼。下户部侍郎唐胄于狱。秋七月辛卯，开河南、云南银矿。癸巳，慈宁宫成。八月甲辰，吉囊犯河西，总督都御史刘天和御却之。丙辰，礼部尚书掌詹事府事顾鼎臣兼文渊阁大学士，预机务。九月戊寅，免畿内被灾税粮。辛巳，上太宗庙号成祖，献皇帝庙号睿宗，遂奉睿宗神主祔太庙，跻武宗上。辛卯，大享上帝于元极宝殿，奉睿宗配。乙未，如天寿山。丁酉，还宫。冬十一月辛未朔，诣南郊，上皇天上帝号。还诣太庙，上太祖高皇帝、高皇后尊号。辛卯，祀天于南郊，诏赦天下。乙未，免江西被灾税粮。十二月癸卯，章圣皇太后崩。壬子，如大峪山相视山陵。甲寅，还宫。乙卯，李时卒。戊午，振宁夏灾。是年，琉球、土鲁番入贡。十八年春二月庚子朔，立皇子载壑为皇太子，封载厚为裕王，载圳景王。辛丑，诏赦天下。起黄绾为礼部尚书，宣谕安南。壬寅，起翟銮为兵部尚书兼右都御史，充行边使。丁未，祈谷于元极宝殿。先贤曾子裔孙质粹为翰林院世袭五经博士。壬子，振辽东饥。癸丑，安南莫方瀛请降。乙卯，幸承天，太子监国。辛酉，次真定，望于北岳。丁卯，次卫辉，行宫火。三月己巳，渡河，祭大河之神。辛未，次钧州，望于中岳。甲戌，免畿内被灾税粮。庚辰，至承天。辛巳，谒显陵。甲申，享上帝于龙飞殿，奉睿宗配，秩于国社、国稷，徧群祀。戊子，御龙飞殿受贺，诏赦天下，给复承天三年，免湖广明年田赋五之二，畿内、河南三之一。夏四月壬子，至自承天。壬戌，免湖广被灾税粮。甲子，幸大峪山。丙寅，还宫。秋闰七月庚申，葬献皇后于显陵。辛酉，复命仇鸾、毛伯温征安南。九月辛酉，如天寿山。侍郎王杲振河南饥。冬十月丙寅，还宫。十一月丙申，祀天于南郊。是年，日本、哈密入贡。十九年春正月丙午，召翟銮复入阁。辛亥，吉囊寇大同，杀指挥周岐。三月戊戌，诏修仁寿宫。夏六月辛巳，瓦剌部长款塞。秋七月癸卯，吉囊入万全右卫，总兵官白爵逆战于宣平，败之。壬子，又败之于桑乾河。戊午，振江西灾。八月丁丑，太仆卿杨最谏服丹药，予杖死。九月，吉囊犯固原，周尚文败之于黑水苑，延绥总兵官任杰追击于铁柱泉，又败之。己酉，召仇鸾还。冬十月庚申，罢矿场。甲子，顾鼎臣卒。十一月丙辰，慈庆宫成。是年，琉球、日本入贡。二十年春正月，免南畿被灾税粮。二月乙丑，显陵成，给复承天三年。丙寅，御史杨爵言时政，下锦衣卫狱。三月乙巳，赐沈坤等进士及第、出身有差。是春，吉囊寇兰州，参将郑东战死。夏四月己未，莫登庸纳款，改安南国为安南都统使司，以登庸为都统使。辛酉，九庙灾，毁成祖、仁宗主。丙子，诏行宽恤之政。五月戊子，采木于湖广、四川。甲寅，振辽东饥。六月，振畿内、山西饥。秋七月丁酉，俺答、阿不孩遣使款塞求贡，诏却之。是月，免河南、陜西、山东被灾税粮。八月辛酉，昭圣皇太后崩。庚辰，夏言罢。是月，俺答、阿不孩、吉囊分道入寇，总兵官赵卿帅京营兵，都御史翟鹏理军务御之。九月乙未，翊国公郭勋有罪，下狱死。辛亥，俺答犯山西，入石州。冬十月癸丑，振山西被寇者，复徭役二年。丁卯，召夏言复入阁。十一月辛卯，葬敬皇后于泰陵。丙申，免四川被灾税粮。是年，琉球入贡。二十一年夏四月庚申，大高元殿成。闰五月戊辰，俺答、阿不孩遣使款大同塞，巡抚都御史龙大有诱杀之。六月辛卯，俺答寇朔州。壬寅，入雁门关。丁未，犯太原。秋七月己酉朔，日有食之。夏言罢。己未，俺答寇潞安，掠沁、汾、襄垣、长子，参将张世忠战死。八月辛巳，募兵于直隶、山东、河南。壬午，振山西被兵州县，免田租。癸巳，礼部尚书严嵩兼武英殿大学士，预机务。九月癸亥，员外郎刘魁谏营雷殿，予杖下狱。冬十月丁酉，宫人谋逆伏诛。磔端妃曹氏、宁嫔王氏于市。是年，免畿内、陜西、河南、福建被灾税粮。安南入贡。 </p> 世宗二</h1> 二十二年春正月丙午朔，日有食之。三月庚戌，复遣使采木湖广。是春，俺答屡入塞。秋八月，犯延绥，总兵官吴瑛等击败之。冬十月，朵颜入寇，杀守备陈舜。十二月乙酉，免南畿被灾税粮。是年，占城、土鲁番、撒马儿罕、天方、乌斯藏入贡。二十三年春正月丙寅，俺答犯黄崖口。二月戊寅，犯大水谷。三月癸丑，犯龙门所。丁巳，赐秦鸣雷等进士及第、出身有差。秋七月，俺答犯大同，总兵官周尚文战于黑山，败之。八月甲午，翟銮罢。九月癸卯，免浙江被灾税粮。丁未，吏部尚书许赞兼文渊阁大学士，礼部尚书张璧兼东阁大学士，预机务。壬子，振湖广灾。冬十月戊辰，免河南被灾税粮。甲戌，小王子入万全右卫。戊寅，掠蔚州，至于完县，京师戒严。乙酉，逮总督宣大兵部尚书翟鹏、巡抚蓟镇佥都御史朱方下狱，鹏谪戍，方杖死。十一月庚子，京师解严，加方士陶仲文少师。十二月丙子，振江西灾。是年，安南入贡，日本以无表却之。二十四年春二月戊申，诏流民复业予牛种，开垦閒田者给复十年。三月壬午，逮总督宣大兵部侍郎张汉下狱，谪戍。夏五月壬戌朔，日有食之。六月壬辰，太庙成。是夏，免畿辅、山西、陜西被灾税粮。秋七月壬戌，有事于太庙，赦徒罪以下。八月丙午，瘗暴骸。己酉，张璧卒。庚戌，俺答犯松子岭，杀守备张文瀚。是月，犯大同，参将张凤、指挥刘钦等战死。九月丁丑，召夏言入阁。冬十一月辛巳，许赞罢。是年，安南、琉球、乌斯藏入贡。二十五年春三月戊辰，四川白草番乱。夏五月戊辰，俺答款大同塞，边将杀其使。六月甲辰，犯宣府，千户汪洪战死。秋七月癸酉，以醴泉出承华殿，廷臣表贺，停诸司封事二十日。嗣后庆贺斋祀悉停封奏。是月，俺答犯延安、庆阳。八月壬子，免山东被灾税粮。九月，俺答犯宁夏。冬十月丁亥，犯清平堡，游击高极战死。癸巳，代府奉国将军充灼谋反，伏诛。甲午，杀故建昌侯张延龄。十二月丁未，免河南被灾税粮。是年，土鲁番入贡。二十六年春三月庚午，赐李春芳等进士及第、出身有差。夏四月乙巳，巡抚四川都御史张时彻、副总兵何卿讨平白草叛番。己酉，俺答求贡，拒之。秋七月丙辰，河决曹县。八月丙戌，免陜西被灾税粮。九月戊辰，户部尚书王杲以科臣劾其通贿下狱遣戍。闰月丙午，振成都饥。冬十一月壬午，大内火。释杨爵于狱。乙未，皇后崩。十二月辛酉，逮甘肃总兵官仇鸾。乙亥，海寇犯宁波、台州。是年，琉球入贡。二十七年春正月，把都儿寇广宁，参将阎振战死。癸未，以议复河套，逮总督陜西三边侍郎曾铣，杖给事中御史于廷，罢夏言。三月癸巳，杀曾铣，逮夏言。癸卯，出仇鸾于狱。夏五月丙戌，葬孝烈皇后。秋七月戊寅，京师地震。庚子，西苑进嘉谷，荐于太庙。八月丁巳，俺答犯大同，指挥顾相等战死，周尚文追败之于次野口。九月壬午，犯宣府，深入永宁、怀来、隆庆，守备鲁承恩等战死。乙未，免陜西被灾税粮。冬十月癸卯，杀夏言。十一月乙未，诏抚按官采生沙金。是年，日本入贡。二十八年春二月乙巳，振陜西饥。辛亥，南京吏部尚书张治为礼部尚书兼文渊阁大学士，祭酒李本为少詹事兼翰林学士，入阁预机务。壬子，俺答犯宣府，指挥董旸等败没，遂东犯永宁，关南大震。乙卯，周尚文败俺答于曹家庄。丙辰，宣府总兵官赵国忠又败之于大滹沱。三月辛未朔，日有食之。丁亥，皇太子薨。秋七月，浙江海贼起。九月，朵颜三卫犯辽东。冬十月辛丑，免畿内被灾税粮。是年，日本、琉球入贡。二十九年春三月壬午，赐唐汝楫等进士及第、出身有差。是月，琼州黎贼平。六月丁巳，俺答犯大同，总兵官张达、副总兵林椿战死。是夏，免陜西、河南、江北被灾夏税。秋八月丙寅，封方士陶仲文为恭诚伯。丁丑，俺答大举入寇，攻古北口，蓟镇兵溃。戊寅，掠通州，驻白河，分掠畿甸州县，京师戒严。召大同总兵官仇鸾及河南、山东兵入援。壬午，薄都城，仇鸾为平虏大将军，节制诸路兵马，巡抚保定都御史杨守谦提督军务，左谕德赵贞吉宣谕诸军。癸未，始御奉天殿戒敕群臣。甲申，寇退，逮守通州都御史王仪。丙戌，京师解严。杖赵贞吉，谪外任。丁亥，仇鸾败绩于白羊口。兵部尚书丁汝夔、巡抚侍郎杨守谦有罪弃市。杖左都御史屠侨、刑部侍郎彭黯。九月辛卯，振畿内被寇者。乙未，罢团营，复三大营旧制，设戎政府，以仇鸾总督之。丁酉，罢领营中官。戊申，免畿内被灾税粮。壬子，废郑王厚烷为庶人。冬十月甲戌，张治卒。十一月癸巳，分遣御史选边军入卫。壬寅，祧仁宗，祔孝烈皇后于太庙。是年，琉球入贡。三十年春三月壬辰，开马市于宣府、大同，兵部侍郎史道经理之。夏四月壬午，下经略京城副都御史商大节于狱。秋九月乙未，京师地震，诏修省。冬十一月，俺答犯大同。是年，免两畿、河南、江西、辽东、贵州、山东、山西被灾税粮。三十一年春正月壬辰，俺答犯大同。甲午，入弘赐堡。二月癸丑，振宣、大饥。辛酉，俺答犯怀仁川，指挥佥事王恭战死。己巳，建内府营，操练内侍。三月戊子，大将军仇鸾帅师赴大同。辛卯，礼部尚书徐阶兼东阁大学士，预机务。夏四月丙寅，把都儿、辛爱犯新兴堡，指挥王相等战死。丙子，倭寇浙江。五月甲申，召仇鸾还。戊申，倭陷黄岩。秋七月丙申，免陜西被灾夏税。壬寅，以倭警命山东巡抚都御史王忬巡视浙江。八月己未，收仇鸾大将军印，寻病死。乙亥，戮仇鸾尸，传首九边。己卯，俺答犯大同，分掠朔、应、山阴、马邑。九月乙酉，犯山西三关。壬辰，犯宁夏。丁酉，河决徐州。庚子，兵部侍郎蒋应奎、左通政唐国卿以冒边功杖于廷。癸卯，罢各边马市。冬十月己未，兵部尚书赵锦坐仇鸾党戍边。壬戌，免江西被灾税粮。十二月丁巳，光禄少卿马从谦坐诽谤杖死。三十二年春正月戊寅朔，日食，阴云不见。己卯，侍郎吴鹏振淮、徐水灾。二月甲子，倭犯温州。壬申，俺答犯宣府，参将史略战死。三月丁丑，振陜西饥。辛巳，吉能犯延绥，杀副总兵李梅。壬午，兵部侍郎杨博巡边。甲申，振山东饥。甲午，赐陈谨等进士及第、出身有差。甲辰，俺答犯宣府，副总兵郭都战死。闰三月，海贼汪直纠倭寇濒海诸郡，至六月始去。秋七月戊午，俺答大举入寇，犯灵邱、广昌。乙丑，河套诸部犯延绥。己巳，俺答犯浮图峪，游击陈凤、朱玉御之。庚午，河南贼师尚诏陷归德及柘城、鹿邑。八月丙子，小王子犯赤城。丙申，师尚诏攻太康，官军与战于鄢陵，败绩。戊戌，振山东灾，免税粮。九月丙午，俺答犯广武，巡抚都御史赵时春败绩，总兵官李涞、参将冯恩等力战死。辛酉，以敌退告谢郊庙。冬十月甲戌，振河南、山东饥。庚子，师尚诏伏诛，贼平。辛丑，京师外城成。是年，琉球入贡。三十三年春正月壬寅朔，以贺疏违制，杖六科给事中于廷。戊辰，官军围倭于南沙，五阅月不克，倭溃围出，转掠苏、松。二月庚辰，官军败绩于松江。乙丑，倭犯通、泰，余众入青、徐界。夏四月甲戌，振畿内饥。乙亥，倭犯嘉兴，都司周应桢等战死。乙酉，陷崇明，知县唐一岑死之。五月壬寅，倭掠苏州。丁巳，南京兵部尚书张经总督军务，讨倭。六月癸酉，俺答犯大同，总兵官岳懋战死。己丑，侍郎陈儒振大同军士。秋八月癸未，倭犯嘉定，官军败之。庚寅，复战，败绩。九月丁卯，俺答犯古北口，总督杨博御却之。是年，暹罗、土鲁番、天方、撒马儿罕、乌斯藏入贡。三十四年春正月丁酉朔，倭陷崇德，攻德清。二月丙戌，工部侍郎赵文华祭海，兼区处防倭。是月，俺答犯蓟镇，参将赵倾葵等战死。三月甲寅，苏松兵备副使任环败倭于南沙。夏四月戊子，俺答犯宣府，参将李光启被执，不屈死。五月甲午，总督侍郎张经、副总兵俞大猷击倭于王江泾，大破之。乙巳，倭分道掠苏州属县。己酉，逮张经下狱。六月壬午，兵部侍郎杨宜总督军务，讨倭。秋七月乙巳，倭陷南陵，流劫芜湖、太平。丙辰，犯南京。八月壬辰，苏松巡抚都御史曹邦辅败倭于浒墅。九月乙未，赵文华及巡按御史胡宗宪击倭于陶宅，败绩。丙午，俺答犯大同、宣府。戊午，犯怀来，京师戒严。辛酉，参将马芳败寇于保安。是秋，免江北、山东被灾秋粮。冬十月庚寅，杀张经及巡抚浙江副都御史李天宠、兵部员外郎杨继盛。辛卯，倭掠宁波、台州，犯会稽。十一月壬辰朔，日有食之。庚申，倭犯兴化、泉州。闰月丁丑，免畿内水灾税粮。十二月甲午，开山东、四川银矿。壬寅，山西、陜西、河南地大震，河、渭溢，死者八十三万有奇。是年，琉球入贡。三十五年春正月壬午，官军击倭于松江，败绩。二月甲午，振平阳、延安灾。己亥，杨宜罢。戊午，吏部尚书李默坐诽谤下锦衣卫狱，论死。巡抚侍郎胡宗宪总督军务，讨倭。三月丁丑，赐诸大绶等进士及第、出身有差。夏四月丙申，振陜西灾。甲辰，倭寇无为州，同知齐恩战死。辛亥，游击宗礼击倭于崇德，败没。五月乙丑，赵文华提督江南、浙江军务。丁亥，左通政王槐采矿银于玉旺峪。六月丙申，总兵官俞大猷败倭于黄浦。辛丑，俺答犯宣府，杀游击张纮。秋七月辛巳，胡宗宪破倭于乍浦。八月壬寅，诏采芝。辛亥，胡宗宪袭破海贼徐海于梁庄。九月乙丑，徽王载𫭢有罪，废为庶人。免南畿被灾税粮。壬午，以平浙江倭祭告郊庙社稷。冬十月丙戌朔，日有食之。十一月戊午，打来孙犯广宁，总兵官殷尚质等战死。十二月丁未，犯环庆三十六年春二月，俺答犯大同。三月癸丑，把都儿寇迁安，副总兵蒋承勋力战死。是月，吉能寇延绥，杀副总兵陈凤。夏四月丙申，奉天、华盖、谨身三殿灾。壬寅，下诏引咎修斋五日，止诸司封事，停刑。五月癸丑，倭犯扬、徐，入山东界。癸亥，采木于四川、湖广。辛未，倭犯天长、盱眙，遂攻泗州。丙子，犯淮安。六月乙酉，兵备副使于德昌、参将刘显败倭于安东。甲午，罢陜西矿。秋七月庚午，诏广东采珠。九月，俺答子辛爱寇应、朔，毁七十余堡。冬十一月丁丑，辛爱围右卫城。是冬，免山东、浙江被灾税粮。是年，琉球入贡。三十七年春正月癸亥，罢河南矿。三月辛未，始免三大营听征官军营造工役。夏四月癸未，振辽东饥。辛巳，倭分犯浙江、福建。秋八月己未，吉能犯永昌、凉州，围甘州。冬十月癸丑，礼部进瑞芝一千八百六十本，诏广求径尺以上者。十一月辛亥，谕法司恤刑。是年，琉球、暹罗入贡。三十八年春二月庚午，把都儿犯潘家口，渡滦河，逼三屯营。三月己卯，掠迁安、蓟州、玉田。庚寅，赐丁士美等进士及第、出身有差。癸巳，倭犯浙东，海道副使谭纶败之。甲午，逮浙江总兵官俞大猷。夏四月丁未，倭犯通州。甲寅，倭攻福州。庚申，倭攻淮安，巡抚凤阳都御史李遂败之于姚家荡，倭退据庙湾。丙寅，副使刘景韶大破倭于印庄。五月辛巳，逮总督蓟辽右都御史王忬下狱。甲午，刘景韶破倭于庙湾，江北倭平。六月乙巳，辛爱犯大同。秋八月己未，李遂、胡宗宪破倭于刘家庄。甲子，振辽东饥，给牛种。是月，俺答犯土木，游击董国忠等战死。九月，犯宣府。是年，土鲁番、天方、撒马儿罕、鲁迷、哈密、暹罗入贡。三十九年春正月丙戌，俺答犯宣府。二月丁巳，南京振武营兵变，杀总督粮储侍郎黄懋官。戊午，振顺天、永平饥。倭犯潮州。三月癸未，大同总兵官刘汉袭败兀慎于灰河。丁亥，打来孙犯广宁，陷中前所，杀守备武守爵、黄廷勋。夏五月壬午，振山西三关饥。壬辰，盗入广东博罗县，杀知县舒颛。秋七月乙丑朔，把都儿犯蓟西，游击胡镇御却之。庚午，刘汉袭俺答于丰州，破之。九月己巳，俺答犯朔州、广武。冬十二月，土蛮犯海州东胜堡。是月，闽、广贼犯江西。是年，免畿内、山西、山东、湖广、陜西被灾税粮。暹罗入贡。四十年春二月辛卯朔，日当食不见。振山东饥。丁未，景王之国。三月壬戌，振京师饥。夏四月丁未，振山西饥。五月乙亥，李本以忧去。闰月丙辰，贼犯泰和，杀副使汪一中、指挥王应鹏。秋七月己丑朔，日有食之。庚戌，俺答犯宣府，副总兵马芳御却之。九月庚子，犯居庸关，参将胡镇御却之。辛丑，振南畿灾。冬十一月甲午，礼部尚书袁炜为户部尚书兼武英殿大学士，预机务。庚戌，吉能犯宁夏，进逼固原。辛亥，万寿宫灾。十二月丙寅，把都儿犯辽东盖州。是年，乌斯藏入贡。四十一年春三月辛卯，白兔生子，礼部请告庙，许之，群臣表贺。壬寅，赐申时行等进士及第、出身有差。己酉，重作万寿宫成。夏五月壬寅，严嵩罢。壬子，土蛮攻汤站堡，副总兵黑春力战死。秋九月壬午，三殿成，改奉天曰皇极，华盖曰中极，谨身曰建极。冬十月，免南畿、江西被灾税粮。十一月乙酉，分遣御史访求方士法书。丁亥，逮胡宗宪，寻释之。辛丑，吉能犯宁夏，副总兵王勋战死。己酉，倭陷兴化。是月，延绥总兵官赵岢分部出塞袭寇，败之。免陜西、湖广被灾及福建被寇者税粮。是年，琉球入贡。四十二年春正月戊申，俺答犯宣府，南掠隆庆。夏四月庚申，倭犯福清，总兵官刘显、俞大猷合兵歼之。丁卯，副总兵戚继光破倭于平海卫。秋八月乙亥，总兵官杨照袭寇于广宁塞外，力战死。冬十月丁卯，辛爱、把都儿破墙子岭入寇，京师戒严，诏诸镇兵入援。戊辰，掠顺义、三河，总兵官孙膑败死。乙亥，大同总兵官姜应熊御寇密云，败之。十一月丁丑，京师解严。是年，琉球入贡。四十三年春正月壬辰，土蛮黑石炭寇蓟镇，总兵官胡镇、参将白文智御却之。二月己酉，伊王典柍有罪，废为庶人。戊午，倭犯仙游，总兵官戚继光大败之，福建倭平。闰月丙申，盗据漳平，知县魏文瑞死之。三月己未，官军击潮州倭，破之。夏四月乙亥，免畿内被灾税粮。五月壬寅朔，日有食之。乙卯，获桃于御幄，群臣表贺。六月辛卯，倭犯海丰，俞大猷破之。冬十二月，南韶贼起，守备贺铎、指挥蔡允元被执，死之。俺答犯山西，游击梁平、守备祁谋战死。是年，西番、哈密、安南入贡。鲁迷国贡狮子。四十四年春三月丁巳，赐范应期等进士及第、出身有差。己未，袁炜致仕。辛酉，严世蕃伏诛。是月，土蛮犯辽东，都指挥线补衮、杨维藩战死。夏四月庚辰，吏部尚书严讷、礼部尚书李春芳并兼武英殿大学士，预机务。壬午，俺答犯肃州，总兵官刘承业御却之。六月甲戌，芝生睿宗原庙柱，告庙受贺，遂建玉芝宫。秋八月壬午，获仙药于御座，告庙。冬十一月癸卯，严讷致仕。戊申，奉安献皇帝、后神主于玉芝宫。是年，琉球入贡。四十五年春二月癸亥，户部主事海瑞上疏，下锦衣卫狱。是月，俞大猷讨广东山贼，大破之。浙江、江西矿贼陷婺源。三月己未，吏部尚书郭朴兼武英殿大学士，礼部尚书高拱兼文渊阁大学士，预机务。夏四月壬戌朔，日有食之。丙戌，俺答犯辽东。六月丙子，旱，亲祷雨于凝道雷轩。越三日雨，群臣表贺。秋七月乙未，俺答犯万全右卫。冬十月丁卯，犯固原，总兵官郭江败死。癸酉，犯偏头关。闰月甲辰，犯大同，参将崔世荣力战死。十一月己未，帝不豫。十二月庚子，大渐，自西苑还乾清宫。是日崩，年六十，遗诏裕王嗣位。隆庆元年正月，上尊谥，庙号世宗，葬永陵。赞曰：世宗御极之初，力除一切弊政，天下翕然称治。顾迭议大礼，舆论沸腾，幸臣假托，寻兴大狱。夫天性至情，君亲大义，追尊立庙，礼亦宜之。然升祔太庙而跻于武宗之上，不已过乎。若其时纷纭多故，将疲于边，贼讧于内，而崇尚道教，享祀弗经，营建繁兴，府藏告匮，百余年富庶治平之业，因以渐替。虽剪剔权奸，威柄在御，要亦中材之主也矣。</p> 素书 2024-07-31T00:00:00+00:00 原始章</h1> 夫道、德、仁、义、礼五者，一体也。</p> 道者，人之所蹈，使万物不知其所由。德者，人之所得，使万物各得其所欲。仁者，人之所亲，有慈慧恻隐之心，以遂其生存。义者，人之所宜，赏善罚恶，以立功立事。礼者，人之所履，夙兴夜寐，以成人伦之序。</p> 夫欲为人之本，不可无一焉。</p> 贤人君子，明于盛衰之道，通乎成败之数，审乎治乱之势，达乎去就之理。</p> 故潜居抱道以待其时。若时至而行，则能极人臣之位；得机而动，则能成绝代之功。如其不遇，没身而已。是以其道足高，而名重于后代。</p> 正道章</h1> 德足以怀远，信足以一异，义足以得众，才足以鉴古，明足以照下，此人之俊也。</p> 行足以为仪表，智足以决嫌疑，信可以使守约，廉可以使分财，此人之豪也。</p> 守职而不废，处义而不回，见嫌而不苟免，见利而不苟得，此人之杰也。</p> 求人之志章</h1> 绝嗜禁欲，所以除累；抑非损恶，所以禳过；贬酒阙色，所以无污；避嫌远疑，所以不误；博学切问，所以广知；高行微言，所以修身；恭俭谦约，所以自守；深计远虑，所以不穷；亲仁友直，所以扶颠；近恕笃行，所以接人；任材使能，所以济物；殚恶斥谗，所以止乱；推古验今，所以不惑；先揆后度，所以应卒。设变致权，所以解结；括囊顺会，所以无咎；橛橛梗梗，所以立功；孜孜淑淑，所以保终。</p> 本德宗道章</h1> 夫志心笃行之术，长莫长于博谋，安莫安于忍辱；先莫先于修德，乐莫乐于好善；神莫神于至诚，明莫明于体物；吉莫吉于知足，苦莫苦于多愿；悲莫悲于精散，病莫病于无常；短莫短于苟得，幽莫幽于贪鄙；孤莫孤于自恃，危莫危于任疑，败莫败于多私。</p> 遵义章</h1> 以明示下者暗，有过不知者蔽，迷而不返者惑，以言取怨者祸，令与心乖者废，后令缪前者毁。怒而无威者犯，好众辱人者殃；戮辱所任者危，慢其所敬者凶。</p> 貌合心离者孤，亲谗远忠者亡。</p> 近色远贤者昏，女谒公行者乱，私人以官者浮，凌下取胜者侵，名不胜实者耗。</p> 略己而责人者不治，自厚而薄人者弃废，以过弃功者损，群下外异者沦，既用不任者疏，行赏吝色者沮，多许少与者怨，既迎而拒者乖。</p> 薄施厚望者不报，贵而忘贱者不久，念旧恶而弃新功者凶，用人不得天者殆，强用人者不畜。为人择官者乱，失其所强者弱，决策于不仁者险，阴计外泄者败，厚敛薄施者凋。战士贫游士富者衰。货赂公行者昧。</p> 闻善忽略，记过不忘者暴。所任不可信，所信不可任者浊，牧人以德者集，绳人以刑者散。小功不赏，则大功不立；小怨不赦，则大怨必生。赏不服人，罚不甘心者叛。赏及无功，罚及无罪者酷。听谗而美，闻谏而仇者亡。</p> 能有其有者安，贪人之有者残。</p> 安礼章</h1> 怨在不舍小过，患在不预定谋；福在积善，祸在积恶；饥在贱农，寒在堕织；安在得人，危在失上；富在迎来，贫在弃时。</p> 上无常躁，下多疑心；轻上生罪，侮下无亲；近臣不重，远臣轻之；自疑不信人，自信不疑人；枉士无正友，曲上无直下；危国无贤人，乱政无善人。</p> 爱人深者求贤急，乐得贤者养人厚；国将霸者士皆归，邦将亡者贤先避；地薄者大物不产，水浅者大鱼不游；树秃者大禽不栖，林疏者大兽不居；山峭者崩，泽满者溢。弃玉取石者盲，羊质虎皮者辱；衣不举领者倒，走不视地者颠；柱弱者屋坏，辅弱者国倾；足寒伤心，人怨伤国；山将崩者，下先隳；国将衰者，人先弊；根枯枝朽，人困国残；与覆车同轨者倾，与亡国同事者灭。见已往，慎将来；恶其迹者，预避之。</p> 畏危者安，畏亡者存。夫人之所行，有道则吉，无道则凶。</p> 吉者，百福所归；凶者，百祸所攻；非其神圣，自然所钟。</p> 务善策者，无恶事；无远虑者，有近忧。重可使守固，不可使临阵。贪可使攻取，不可使分阵。廉可使守主，不可使应机。五者各随其材而用之。</p> 同志相得，同仁相忧，同恶相党，同爱相求，同美相妒，同智相谋，同贵相害，同利相忌，同声相应，同气相感，同类相依，同义相亲，同难相济，同道相成，同艺相规，同巧相胜。此乃数之所得，不可与理违。</p> 释己以教人者逆，正己而化人者顺。逆者难从，顺者易行；难从则乱，易行则理。</p> 详体而行，理身、理家、理国可也。</p> 有效激励&有效沟通培训笔记 2023-10-26T00:00:00+00:00 有效激励</h1> 多种需求共存，只有一个占主导地位。</p> 需求结构动态变化，从内向外，从下向上。</p> 双因素理论。</p> 保健因素，激励因素。</p> 组织目标-高水平努力-个体需要</p> 投其所好，但坚守原则</p> $$\frac{Op}{lp}=\frac{Oa}{la}$$</p> 高意愿，高能力：重用</p> 低意愿，高能力：挽救or勿留</p> 高意愿，低能力：新人</p> 低意愿，低能力：低风险重复工作</p> --- </span>title: 意愿&能力象限 </span>config: </span> theme: dark </span>--- </span>quadrantChart </span> </span>x-axis "高意愿" --> "低意愿" </span>y-axis "低能力" --> "高能力" </span> </span>quadrant-1 "挽救" </span> </span>quadrant-2 "重用" </span> </span>quadrant-3 "新人" </span> </span>quadrant-4 "监督质量" </span> </span></code></pre> 关注事，更要关注人</p> 不要上来直接谈工作</p> 工作与非工作内容不要一起谈</p> 谈日常生活以员工为中心</p> 关心琐事</p> 赞美</p> 挑战型工作</p> 参与式管理（代理参会）</p> 正确批评下属</p> 抱怨是激励方案的重要来源</p> 乐于倾听抱怨</p> 详细了解抱怨的真实原因</p> 及时处理或向上反应，形成闭环</p> 不合理的抱怨进行有效沟通</p> 管理工作就是激励</p> 超过他现有水平，在他人帮助下能完成的</p> 工作量，工作标准，工作难度，工作进度</p> 长处和爱好</p> 提供资源</p> 提醒求助</p> 达成详细的评级标准</p> 批评下属</p> 三明治法</p> 你拥有无尽的激励资源</p> 自我激励与激励他人</p> 作业：</p> 建立下属的信息档案</li> 一周内无成本的激励2名下属</li> </ol> 如何建立员工档案</p> 学校</li> 家庭情况</li> 状态</li> 历史沟通记录</li> 个人追求，发展路径，与性格相匹配</li> 想了解什么？</li> 对问题的洞察力考察，评价视野如何，Ego如何业务挑战是什么？</li> 为什么会有这样的挑战？</li> 公司最大的机会或机遇</li> 我们如何抓住机遇</li> 角色互换会怎么做</li> </ol> </li> </ol> 有效沟通</h1> 对上，对下，周边</p> 除去睡眠，70%的时间用于信息获取</p> 70%的错误是因为不善于沟通</p> 正确的时机，正确的场合，正确的信息，正确的对象</p> 信息流失原理</p> --- </span>title: 乔哈里视窗 </span>--- </span>%%{init: {'theme':'dark'}}%% </span>quadrantChart </span> </span>x-axis "我知" --> "我不知" </span>y-axis "你不知" --> "你知" </span> </span>quadrant-1 "盲目区" </span> </span>quadrant-2 "开放区" </span> </span>quadrant-3 "隐藏区" </span> </span>quadrant-4 "未知区" </span></code></pre> 沟通如果处在盲目区/未知区，容易出现信任危机</p> 专业，敬业，真诚与诚意</p> 尊重，关爱，信任</p> 积极主动</p> 5W1H</p> 同理心</p> 面对面</p> 优：直观，身体语言，易于讲真</p> 缺：时间匹配，立即思考，不易结束</p> 会议</p> 优：工具，传达，集思广益</p> 缺：耗时，杂乱，极端化</p> 电话</p> 优：迅速，方便</p> 缺：误解，没有记录</p> 邮件：</p> 优：简短，有据，多准备</p> 缺：反馈慢，无法控制对方行为</p> 不要转发邮件or群组批评邮件</p> 少用感叹号和问号</p> 尽量不用反问句</p> 重要性不高不要抄送主管</p> 不要用邮件吵架</p> 倾听</p> 说明原因</p> 说明终止日期</p> 说明工作方案</p> 说明时间期限</p> 说明执行程度</p> 及时表扬（公开）</p> 适时批评（私下）</p> 冲突化解</p> 消除信息盲区</p> 70%的问题来自于情绪</p> 认清沟通的价值</p> 上一次沟通的课程</p> 绩效沟通的时候，同理心的使用</p> 情绪是无法隐藏的，调整好自己</p> 把心态放正，保证更开放的思考</p> 对事实的调查，自己的公正心态更重要。</p> 细微的小事也要讨论。</p> 清晰的阐述问题很重要，在阐述过程中有解决问题的思考。</p> 信息 or 价值观沟通 or 选择</p> 冲突型沟通，要先设定前提，有同理心，准则</p> 不要给上司做问答题，提供选择题式的方案</p> 要有答案，要有对策</p> 对于下发的任务要保证听懂，当场确认细节</p> 探讨可行性</p> 详细计划，反馈频次</p> 尊重不吹捧，请示不依赖，主动不越权</p> 资讯和数据更有说服力</p> 提方案的方法：如何实现如何证实结果如何</p> 如何辅导下属</p> 辅导但不动手，习惯依赖他人决策</p> SMART化，5W1H</p> 信息不对称&预设立场</p> 周边沟通</p> 高看自己，看低他人</li> 不能换位思考</li> 失去权力</li> 职权划分</li> 甩锅</li> 利益冲突，唯恐别人比自己强</li> </ol> 如何做好周边沟通</p> 加强交流，注重沟通</li> 保持友好，把握距离</li> 互相合作，积极竞争</li> </ol> 作业：针对你在日常沟通中的困惑做出改进计划，使用课堂学到的技巧尝试。</p> 赖德·卡罗尔-《子弹笔记》-读书笔记 2023-08-28T00:00:00+00:00 《子弹笔记》看到kindle的广告推荐，其实一直也在寻求一种可靠的笔记方法，便咬咬牙买了。认真读完，果然物超所值。</p> 子弹笔记是一种简洁的、结构化的、模块化的、个性化的笔记方法。子弹笔记的核心目标就是为了增加日常思考，记录生活细节。下称bujo(bulletjournal的缩写)</p> 为什么要动手写字：我本人是从不推荐抄写的，但是记录笔记是思维精炼，处理信息的一种非常好的方法。一、模块化 bujo的模块被书中译为“集子collections”。作者只基于最精简的方式，推荐了四种集子</p> 索引：位于笔记本前几页，笔记要求必须有页码，这样索引就像是书籍目录，有这样一个可扩展的目录，就可以快速的定位信息。</li> 未来记录：位于索引的后4页，用来定制未来计划。未来记录的内容来源于日常记录或月度记录的迁移，以及目标展开时的阶段制定。</li> 月度记录：</li> </ol> 月度记录在每个月开始的第一天，或者上一月的最后一点制作，一个笔记本中，会有多个月度记录。月度记录需要横向展开的两页。左侧页为日历，依次写下日期和星期。右侧页为本月任务。</p> 每日记录：每日记录是bujo中存在最多的集子，不需要单独占页，不需要定义标题，不需要加入索引，只要一直向下的写下去就好了。二、简洁 bujo中定义的一些常用的快速记录标记： — 笔记（用于记录主意、想法、评论，主要使用场景为会议、讲座、课堂）在记录笔记的过程中，需要遵循的中心原则为“把未来的自己放在心上” ○ 事件 · 任务 × 完成的任务</li> </ol> 迁移的任务 < 计划的任务 (· 删除的任务) 附加符号：</p> </blockquote> 优先、重要！灵感三、结构化</li> </ul> 次集子：对集子进行结构化分解，把一个集子的内容扩展成多个次集子。</li> 任务事件结构化在每日记录中，可以把任务细分为多个子任务，具体层级可以按任务内容决定。在任务或事件的下一级，可以在下一级用笔记的形式加入个人的思考或见解。 3.引线法：使用引线法对多个集子甚至多本笔记进行内容关联四、个性化：</li> </ol> 可以按照个人兴趣或生活习惯进行集子的扩展。如，读书清单、影视清单、工作计划、行程计划、生活追踪、目标分析、会议记录甚至是涂鸦，设计等等。创建了新的集子之后一定要写好标题，并在索引中加入相应的索引项。基于这样的个性化扩展后，一本笔记就可以完成所有的日常生活记录，把所有想要输出的内容写在同一本笔记中。</p> 五、任务迁移：</p> 任务迁移在bujo中的作用最大，简单的任务清单是不存在这种任务迁移的概念的，那么有很多短期内无法完成的任务，都变成了一种负担。迁移的过程也是对任务和人生的思考过程，这个任务是否必须完成，对未来目标的影响是否重大。</p> 实际操作：</p> 起步阶段：俗话说万事开头难，不要把目标订的太高，其实我一直也是在记笔记的过程中觉得自己的字太丑，越来越写不下去，最后工作笔记也变成了仅仅在会议中的应付。现在想开了，字丑可能一时半会改变不了，但至少可以先做到清爽，所以现在用铅笔来做笔记。</p> 反思：建议每天睡前进行一次反思，针对今天的任务，也可以思考明天的计划，时间长短自定。论语讲的“三省吾身”也是一样的道理。</p> 意义：ikigai是一种日本的生活哲学，人生的意义，其中有四个要素，热爱的，擅长的，有收入的，世界需要的。这四个要素的重叠部分就是ikigai，bujo可以帮你找到ikigai。在对生活的记录规划和反思中，就是对人生的提炼，那么生活的重心就会越来越趋向于ikigai。</p> 目标：目标简单理解就是白日梦，创建一个目标自己，记录下所有的白日梦，经过筛选，逐渐的提炼出最有意义的目标。筛选目标的方法叫做五四三二一倒计时法则，可以把目标分为短、中、长期。五年、四个月、三周、两天及一小时内的目标。只需要把目标子集中的内容进行分配后就很轻松的分开了目标的长短，然后在用标选出重要目标，再把对应的目标放置到未来记录，月记录中。</p> 循序渐进：要避免直接处理大问题，先把大问题拆解为小问题，那么就要先问自己1，想做什么2，为什么要做3，可以从哪件小事开始。这样才能达到循序渐进的理念。用PDCA的方式持续改进。</p> 时间：给任务定义一个明晰的时间表，这样可以有利于解决拖延，更真正的面对当下。感恩：生活总是充满困苦，而感恩能给人最积极正向的能量，创建一个感恩子集，写下每天感恩的事，让明天带着满满的正能量起航。掌控：掌控的能力就是选择的能力。通过记录，积极的掌控心态、情绪。</p> 辐射力：辐射力就是对他人的影响，即蝴蝶效应。世界往往是从内心开始改变的，在外部压力很大的时候，要学会自我怜悯。记录下自己的心酸，制定一些能安慰自己的活动，想改变，就要从自己开始。</p> 忍耐：列出让自己不开心的难题，分析两难的原因，追踪心境和问题的变化，最后自然水到渠成。拆解：用五问法，把难题拆解为多个小问题，也就是在遇到问题后，问自己五个为什么，就把一个大问题变成了五个小问题，再去把五个小问题逐一解决。</p> 无力感：任何长期目标在实践过程中都会产生无力感，那么就需要“停顿目标”，停顿目标是一个独立的微小项目，用来给自己打气，增加信心。1.时间不超过两周，2，和产生困扰的问题无关。3，要有明确的结尾。这样，完成了停顿目标，就是给了自己一个极大的鼓励，也就重新获得了解决困难问题的能量。</p> 不完美：万物皆有裂痕，那是光进来的地方–莱昂纳德·科恩。练习不完美，便能接受不完美，在犯了错或者开头不顺的时候想要放弃笔记，就在笔记中创建一份不完美集子，可以随意涂鸦，换用非惯用手写字，这样就消除了完美压力，以便笔记能更好的坚持下去。</p> Start - All because Marco Dorantes Blog 2023-08-28T00:00:00+00:00 It’s a very sudden thought. I start a personal blog, only write by myself, and only use English. It’s about all my life. From my born To the last if I can. Today when I search something about software architect, I went to this blog https://docs.microsoft.com/en-us/archive/blogs/marcod/</a> then I saw a blog named “After 18 years posting” it’s quite shack me. I want be a man like him. don’t need post every day. but post 18 years and more. let’s go.</p> Kitty 2022-10-08T18:50:00+00:00 Kitty</h1> can’t copy in emacs -nw</h2> If you’re trying to copy from vim launched in an SSH session, selecting with mouse drag will enter visual mode - so CTRL+SHIFT+C won’t have any effect, because you’re selecting in vim, not kitty. To select in kitty, use SHIFT+left mouse button drag </p> from stackexchange</a> by walnut-salami</a></p> bypass chrome Your connection isn't private 2022-09-14T10:21:00+00:00 How to Bypass Google Chrome show “Your connection isn’t private”</p> step 1. Click a blank section of the denial page.</p> step 2. Using your keyboard, type thisisunsafe</code>. This will add the website to a safe list, where you should not be prompted again.</p> Software Architect 2021-10-11T11:55:00+00:00 </p> What is a software Architect?</h1> The definition in wikipedia is below:</p> A software architect is a software development expert who makes high-level design choices and tries to enforce technical standards, including software coding standards, tools, and platforms.</p> Duty</h1> The role of software architect generally has certain common traits:</p> Software architects make high-level design choices based on their programming experience. In addition, the software architect may sometimes propose technical standards, including coding standards, tools, or platforms.</p> Software architects may also be engaged in the design of the architecture of the hardware environment, or may focus entirely on the design methodology of the code.</p> Architects can use various architectural-oriented software packages that specialize in communicating architecture.</p>