简单点

Appearance

npx prettier scripts/generate-css-vars.mjs --write

-- 2026-01-19 16:31:06

contentHeight 就是 popoverContentHeight，这样就好理解多了。

-- 2026-01-18 09:56:41

popover 组件的 placement 取值有 left/right/top/bottom/top-let/bottom-right/left-top 等，共有 4 个主位置 + 2 * 4 个边边为主 = 12 个选项。

内部把 -left|top 转为 -start，-right|bottom 转为 -end，好处是 API 简单，4个单词的排列组合。

判断是否横向 isHorizontal、是否竖向 isVertical，横向是包含 top/bottom，竖向是包含 left/right，isBase 是4个主位置，isEnd 是包含 end。

是否能正常放置 canPlace，如果是 isHorizontal

js
if (placement.startsWith('top')) {
 canPlace = triggerTop - contentHeight >= 0;
} else if (placement.startsWith('bottom')) {
 canPlace = triggerBottom + contentHeight <= windowHeight;
}

top/left 计算

js
const isTopBase = placement.startsWith('top');
const isBottomBase = placement.startsWith('bottom');
const isLeftBase = placement.startsWith('left');
const isRightBase = placement.startsWith('right');

if (isTopBase) {
  top = triggerRect.top - contentRect.height;
} else if (isBottomBase) {
  top = triggerRect.top + triggerRect.height;
} else if (isLeftBase) {
  left = triggerRect.left - contentRect.width;
} else if (isRightBase) {
  left = triggerRect.left + triggerRect.width;
} else {
  top = triggerRect.top - contentRect.height;
}

-- 2026-01-17 22:19:41

  • 哪些任务交给 AI 最「划算」
  • 怎么让项目本身变得更「AI 友好」，提高一次命中率
  • 当生成不再是瓶颈时，工程师应该如何设计验证流程，把时间花在真正值钱的地方。

两种体验

  • 在新项目、简单逻辑、没有历史包袱的「快乐路径」上，AI 确实像开挂
  • 一旦落到复杂业务、遗留系统、技术债堆积的真实世界，它又经常「看着对，其实不对」

从后端视角看，我最后总结出了一个「甜点区」：

  • 高重复 / 模板化，典型就是各种 CRUD：创建、查询、更新、删除接口，还有重复的校验逻辑、分页查询、条件组合过滤等。
  • 高耗时，纯手写要磨 2–3 小时以上，但创造性不高。
  • 低风险，不是一改错就会把核心业务搞挂的地方。
  • 易验证，验证条件清楚：要么能快速写出测试脚本，要么肉眼就能看出来对不对。

这类工作，说白了就是「不得不写，但写了也没什么成就感」的那一块。AI 很擅长干这种活。

久而久之，我自己的工作重心也发生了结构性变化：过去：大概 80% 时间在写代码，20% 在自测和验证。现在：大概 30% 时间在定义任务、喂上下文、指挥 AI 生成，70% 在严肃地验证结果，写测试、跑脚本、读日志、看监控

落地时我常用三样东西：

  • Rules：硬约束，团队规范的机器可读版
  • Demo：标准答案，few-shot 参考实现
  • Skill：常用流程固化成可复用动作（这块偏自动化，后面接着讲）

简单说，Rules 管「不能错」，Demo 管「照着抄」，Skill 管「反复干」。

-- 2026-01-16 12:50:38

财富就是知识 书中的第一个观点，叫做「 财富就是知识 」，这句话大家可能都有听说过，但我们是否对它理解足够？ 我们试问一下「 财富就是知识 」，是不是「 知识就是财富 」呢？
 虽然看似类似，这两者之间的关系却具有重要的区别。用一个更好理解的方式来看，当我们说「A就是B」，比如「白马是马」，当我们说「是」的时候，意味着后者其实是前者更本质的存在。而反过来，马就不一定是白马了。

所以在这本经济学书里说「 财富就是知识 」的时候，其实是在说财富的本质是知识。 也就是说，如果财富不是知识，它就不是财富。这跟我们以前的理解很不一样——以前我们会理解，财富是资源、资产、土地、房子等等，但是这个结论里面告诉我们，在现在的社会和未来的社会，财富的本质就是知识。

举个例子，有人买了一辆法拉利跑车，花了100万美元，但它为什么值100万美元？并非这辆车材料本身的价值，而是因为将这些材料通过知识转化成汽车的过程创造了超出材料本身之外的额外价值。

又比如说，我们所处的现在社会，与10万 / 20万年前原始人居住的地球，在自然环境、生态方面，并没有太大变化，然而人类的财富却有了巨大的增长。这些财富并不是天然的自然界可以赋予我们的，而是人类创造出来的。创造的背后是我们比10万年前的人多了很多知识。

同样的，商品也可以被源源不断地制造出来，甚至是没有上限的。可以看到的商品都是物质组成的，物质的组成是原子，如果我们用什么方式去重新组合这些原子变成商品，那组合原子的方式就是知识。

如果把组合原子的方式再往前推进一步，我们现在组合原子还需要先去采集、采矿或者找稀有的原材料，但是如果人类的知识再进一步的话，现在就有很多类似这样的技术，比如碳原子可以被做成各式各样的材料。

如果可以直接操作原子的话，那么就可以用原子直接组合成任何的商品形式出来，包括芯片也是，在极小的颗粒度上去操作这些原子的集合。 所以商品是什么，就是原子，这些是物质的东西，加上知识，它就等于商品了。在现实世界也是可以理解的，比如说做一件衣服，买一块布回来，加上你的设计，它就是商品。

当原子变得越来越廉价的时候，知识变得越来越有价值。 这就打破我们固有的认知。举个例子，地球上的人越多，我们会认为地球上负担越重，人均生活质量就会下降。但其实当地球上人越多的时候，比如有100亿、1000亿人的时候，头脑越多，分工越细、知识也会越多。按这样推断的话，那1000亿人所创造的财富总量反而会更多，人均生活会过得更好。

如果体现在我们公司的话，如果还有业务增长，其实取决于我们大家的知识总量，而不是由我们现有多少用户、现有多少产品。

再想象一下，假设50年之后元宇宙技术成熟了，我们真的可以把大脑意识装在电脑里面，在电脑里面模拟出来的世界，大家可以在里面继续生活，甚至在那样的元宇宙里面，可能还有一个“腾讯公司”，我们在里面又相见了。大家还是会买衣服、还是会工作，元宇宙里面也有电脑，也可以写代码。

在那个世界里面没有原子，因为都是电脑模拟出来的，只有信息，只有比特，我们在里面也创造财富，在那个世界里面，财富是跟原子、实物没有关系，全部都是信息化、比特化的，这可能是100年后的事情。但我们现在要知道，我们所创造出来的虚拟东西，价值是越来越大的。

成长就是学习 这跟我们日常了解的「学习就是成长」又是反过来的。「成长就是学习」的意思是，每一个公司或者个人的成长，肯定都有「学习」在发生作用，但学习不一定会导致成长。

举个例子，很多人都知道摩尔定律。但我们想想，为什么摩尔定律会成立呢？ 其实本质上是指数级的成本降低。生产成本变低，表示在生产过程中学习到了更多的知识。像在芯片行业发展的初期，半导体公司在争取国防部订单的时候，甚至是远低于成本价的亏本方式来谈判。因为他们知道，每18个月芯片的集中度就会翻1倍，三年之后，成本就会急剧下降。如果当前不付出代价来争取销售订单，就无法带来规模效应。所以本质是规模效应导致了摩尔定律，这种定律其实也被称之为「学习曲线」。

从这里也可以理解，苏联以前可以很快制造出原子弹，但造不出芯片来。为什么呢？ 因为原子弹不需要有规模效应，只要造1个就可以了，所以可以凭着信念去集中人力造出来。但是芯片不是靠信念可以造出来的。

信息就是惊喜 知识、内容，其实都代表了信息，就像原子代表物质、比特代表信息一样。 克劳德·香农（Claude Shannon）在信息论里，定义了信息的量度方式：信息的量可以通过消息中不确定性的减少来量化。 也就是说，如果一个事件非常不可预测，当它发生时所提供的信息量就很大；相反，如果事件高度可预测，它提供的信息量就小。

信息就是惊喜，就是你猜不到的程度。信息量是由内容的离谱程度来决定的，越离谱信息量就越高。所以大家看很多内容平台，也看到「标题党」，那些标题越离谱，你越会点进去看一下，他们也是无意之间符合了「信息就是惊喜」这样一个基本理论。

这里还可以衍生一个概念，就是「惊喜就是学习」，就是当我们被惊喜到了，我们就学习到了。就像我讲的东西很离谱，但其实大家会学到东西的，因为你没有接触过这个概念，所以你会觉得离谱。但是因为你没有接触过，所以它反而弥补了你这块的知识。

有一次开会，我跟我们同事说，我希望在座的每一个人都分享自己最近一个月里面最失败的一次经历。每个人就分享了一下，所有的人都觉得收获很大。那为什么不是让每个人都分享一个他最成功的案例？因为成功的案例并不离谱，失败才是比较离谱的事情，才是大家不知道的事情，才是大家想要获取的，甚至认为是知识。

从这个角度衍生一下我们日常讨论方案，所有人都认为好的方案，可能并不能创造太大的价值，相反所有人都认为不好的方案，如果你把它做到了，它能创造的价值反而会很大。

以创业公司为例，真正成功的创业公司，他们往往都是在刚开始没人看好的赛道上，获得巨大成功的。而在所有人都看好的某一个赛道，很多很多创业公司，结果却很难获得成功。他们的方案往往太完美了，太好了，以至于他们没有提供信息的增量，反而没有知识的价值了。 当我们在追求确定性方案的时候，可能结果反而不一定会好，这是很有趣的悖论。

金钱就是时间 从经济学的角度来说，金钱就是时间，但时间并不一定是金钱。最早的金钱是黄金，后来出现了纸币，然后出现了比特币，乔治·吉尔德在这本书里讲到，他认为后续会出现时间币，也就是你为了购买一个东西愿意付出多少时间。

乔治·吉尔德在书中提到，乔布斯在2007年1月9日推出了iPhone，它推动了发现与创造知识，并导致了最重要的经济指标的发展，也就是每小时的知识量。时间价格是衡量全球每小时知识的一种方法，也是历史上最大的网络学习曲线。

马斯克曾经接受采访时提到Twitter的目标，定义了一个「让用户更少后悔的消费时长」。 因为很多人会抱怨，在Twitter上浪费了太多时间，感到后悔。马斯克期望团队都去关注这个核心指标。比如TikTok上有很多青少年跳舞的视频，所以它会吸引人们的关注，成为热门话题。而Twitter更多关注智力辩论、新知识、幽默的或突发的新闻。如果Twitter的内容更好或更有趣，大家就会更喜欢Twitter。

结语：解题能力vs出题能力 最后分享一下我所尝试的一些改变。比如以前我跟同事开会，大家都建立了一种能力模式，就是「做题能力」。 每个人都特别擅长做题。面对一个具体命题的时候，他知道应该怎么解答。 我最近在尝试给我的同事们建立一种新的模式或者能力，叫「出题能力」。 你要自己给自己出个题，然后解答出来。我发现大部分的同事是没有这种模式或者能力的。

如果前面说确定性的方案不是最佳方案，那它的反面——应该是不断地假设、不断地验证的一种过程。 不断假设也是一种能力，很多假设都会导致失败，但是十个失败里有1次你尝试成功了，那就非常强，强过了你提出那个非常确定性解决方案的一次成功。

所以我们的工作里面，如果把假设变成一种模式，变成了习惯的话，你会很上瘾，就像听古典音乐一样上瘾。

-- 2026-01-12 02:54:25

  • 本质是方案设计：优秀的 Prompt 源自对问题的深刻洞察，实质是解决方案的精准表达。
  • 组合解决问题：复杂任务需拆解为多个 准确无误 的ICP〔原子化组件〕组合实现。
  • 编排方式明确：ICP 组合采用 固定编排 而非 Agent 自主选择，确保流程可控。
  • 前置知识整理：AlCoding 倒逼梳理核心资产〔如接口文档、注释、架构〕，补齐技术债。
  • 可靠性保障：ICP 的核心价值在于其结果确定性，规避知识库/代码搜索的不准确性。
  • 全周期提效：AlCoding提效需覆盖软件全生命周期〔需求、设计、编码、测试、运维〕。
研效工具集成：必须与现有研发效能工具〔监控、日志等〕深度集成。
  • 面向未来设计：聚焦模型升级后仍有效的基础工作〔如知识整理〕，避免填补当前模型短板。
  • 团队实践驱动：AlCoding 的真正落地增效需团队共同实践验证，非个人体验可达成。
  • 人工评审提效：对AI各环节产出进行多轮人工评审，可显著提升阶段质量，使最终代码更符合需求预期

-- 2026-01-12 02:53:53

适合：

  • 内部组件库（团队级 / 公司级）
  • 业务组件库（电商、金融等垂直领域）
  • 设计系统（Design System）
  • 规模门槛：组件包数量 > 30，维护成本 > 2 人天/月

❌ 不适合：

  • 质量参差不齐的组件库（先提升质量，再建知识库）
  • 缺少类型定义的纯 JS 组件库（无法精准提取 API）
  • 纯样式库（无逻辑组件）
  • 小型项目（< 10 个组件，手动维护更高效）

-- 2026-01-12 02:52:04

  • 如果组件库质量差（类型定义不全、缺少 Demo），再好的 AI 也无法生成高质量文档
  • 如果架构设计不合理（不分层、不排序），检索体验会很差
  • AI 只是锦上添花，数据质量才是根本

-- 2026-01-12 02:50:49

某次腾讯文档xx

  • Uniapp技术选型
  • 赛程为什么不用canvas
  • 国际化原理 安全问题
  • 小程序底层原理

-- 2026-01-12 02:49:25

计算属性只在相关响应式依赖发生改变时它们才会重新求值。这就意味看只要 author.books 还没有发生改变，多次访问 publishedBookMessage 计算属性会立即返回之前的计算结果，而不必再次执行函数。

这也同样意味着下面的计算属性将不再更新，因为 Date.now() 不是响应式依赖：

js
computed: {
  now (){
    return Date.now()
  ｝
｝

-- 2026-01-11 17:35:02

  • 技术优化在业务应用中的稳定性和可靠性：是否能够长时间稳定运行，减少故障发生的概率等一一评审可用性
  • 技术优化带来的产品体验的提升/降本增效的成果或技术重构带来的收益—一评审效率性
  • 技术优化/迭代/创新的意义及对未来的展望一—评审技术价值

-- 2026-01-10 17:40:11

在做中学：不要依赖AI，我们不仅是在打造软件，还在打造个人能力

明确边界：人是决策者，AI负责执行，不能把思考交给AI！

在这一场AI带来的生产力革命中，我们应当坚守以下原则，这也是现代软件工程师需要的思维模式：

  • 怀疑+实证；以学习为中心，将每一次编码、每一次发布都视为学习和验证假设的机会。
  • 拥抱不确定性：承认不足并有信心的在探索中找到答案。
  • 务实：专注于寻找高效、经济的解决方案，而非追求理论上的完美或技术上的炫耀。

在这场从 “写作者”到“指挥家” 的转变中，总结以下核心思路：

  1. 聚焦本质复杂性，外包偶然复杂性

将样板代码、配置、测试补全交给 AI。人类的智慧应当保留在对业务领域逻辑死角的建模和系统边界的划定上。

  1. 掌握业务灵魂（领域模型），以规范（Spec）为核心资产

代码在 AI 时代会成为易耗品。结构化的业务模型与规范是需要精心管理。

如果规范定义正确，你可以随时要求 AI 用 Go 替换当前的 Java。高质量的结构化规范才是你真正的资产。

  1. 将AI当成队友，引导它，帮助它

不要只看 AI 生成的代码。通过自动化测试、UI 截图、性能监控等“感官”数据，建立端到端的验证闭环，确保系统在工程纪律下演进。

软件工程并没有消失，它只是变得更加纯粹。 我们正在步入与AI合作的时代，需要我们细心引导，建立共知共识，协同步入由人定义意图、由 AI 完美执行的“氛围工程”新纪元。

-- 2026-01-09 18:52:30