Skip to content

作者

novlan1

2026.1.1

技术笔记

我怎么编辑这个文件呢,code xx.code-workspace好像不会打开这个文件

2026-05-27

对,code xxx.code-workspace 在 VS Code / CodeBuddy 里是 "以工作区方式打开",不是"编辑这个文件"。要编辑它的内容,有几种方式:

方法 1:当作普通 JSON 文件编辑(最直接)

bash
# 强制以"文件"方式打开编辑
code -r /Users/guowangyang/Documents/git-woa/gp-multi.code-workspace --goto /Users/guowangyang/Documents/git-woa/gp-multi.code-workspace

更简单的写法(先打开一个目录,再把文件拖进去或用 goto):

bash
code /Users/guowangyang/Documents/git-woa
# 然后在左侧资源管理器双击 gp-multi.code-workspace

或者直接用其他编辑器:

bash
# 用系统默认编辑器
open -t /Users/guowangyang/Documents/git-woa/gp-multi.code-workspace

# 或 vim / nano
vim /Users/guowangyang/Documents/git-woa/gp-multi.code-workspace

方法 2:已经在工作区模式下,用命令面板打开

这是最推荐的日常做法——你已经用 workspace 模式打开了 IDE,想编辑挂载列表时:

  1. Cmd+Shift+P 打开命令面板
  2. 输入 Workspaces: Open Workspace Configuration File(中文:"工作区: 打开工作区配置文件"
  3. 回车,IDE 就会把当前那个 .code-workspace 文件作为 JSON 打开供你编辑

保存后立即生效,不用重启。

方法 3:通过 UI 增删文件夹(不用手写 JSON)

在工作区模式下:

  • 加仓库:左侧资源管理器空白处右键 → Add Folder to Workspace... → 选目录
  • 删仓库:右键某个根目录 → Remove Folder from Workspace
  • 改显示名:右键 → Rename(或直接编辑 JSON 里的 name 字段)

这些操作会自动写回 .code-workspace 文件。


关于你截图里的现象再补一句

你之前截图看到 code my-projects.code-workspace 没"打开文件"——那其实是正常行为:它打开的是工作区(左上角标题会变成 xxx (Workspace))。要看 JSON 内容就用上面方法 2 的命令面板,最方便。

需要我帮你把更多 gp 系列仓库或任何特定仓库加进 gp-multi.code-workspace 吗?告诉我列表即可。

code-worspace 解释

2026-05-27

这是 VS Code(Visual Studio Code)多根工作区配置文件.code-workspace),作用是一次性打开多个项目文件夹,并统一配置编辑器规则。

我给你用最通俗、最清晰的方式逐段解释👇

整体作用

这个文件让你:

  1. 同时打开 6 个独立项目(不用一个个打开文件夹)
  2. 统一隐藏不需要看的文件(node_modules、dist 等)
  3. 统一搜索排除、监听排除
  4. 给 TypeScript 分配更大内存

逐段解释

1. folders(核心:同时打开多个项目)

json
"folders": [
  { "name": "gp-next", "path": "gp-next" },
  { "name": "gp-apply", "path": "gp-apply" },
  { "name": "gp-hor", "path": "gp-hor" },
  { "name": "gp-match", "path": "gp-match" },
  { "name": "gp-pixui", "path": "gp-pixui" },
  { "name": "tapd-solution", "path": "1.basic-repos/tapd-solution" }
]

意思:

  • 一次性加载 6 个项目文件夹
  • name:VS Code 左侧显示的名字
  • path:文件夹实际路径

这就是 VS Code 多项目工作区(Multi-root Workspace),专门给微前端、多包仓库、前后端分离项目使用。


2. settings(统一编辑器设置)

A. files.exclude(文件隐藏)
json
"files.exclude": {
  "**/node_modules": true,
  "**/dist": true,
  "**/.history": true
}
  • 在 VS Code 左侧文件树隐藏这些文件夹
  • 你看不到,但它们真实存在
B. search.exclude(搜索排除)
json
"search.exclude": {
  "**/node_modules": true,
  "**/dist": true,
  "**/*.map": true,
  "**/pnpm-lock.yaml": true,
  "**/package-lock.json": true
}
  • 全局搜索(Ctrl+Shift+F)不搜索这些文件
  • 避免搜索结果爆炸、卡顿
C. files.watcherExclude(文件监听排除)
json
"files.watcherExclude": {
  "**/node_modules/**": true,
  "**/dist/**": true,
  "**/.history/**": true
}
  • VS Code 不监听这些文件夹的变化
  • 减少 CPU 占用、防止编辑器卡顿
D. TypeScript 内存配置
json
"typescript.tsserver.maxTsServerMemory": 8192
  • 给 TS 语言服务分配 8GB 内存
  • 解决大型项目 TS 卡顿、CPU 飙高的问题

3. extensions(推荐插件)

json
"extensions": {
  "recommendations": []
}
  • 这里可以写团队共享的插件列表
  • 目前是空的,代表没有推荐插件

一句话总结

这是一个 VS Code 多项目工作区配置,用来:

  • 同时打开 6 个前端项目
  • 统一隐藏无用文件
  • 优化搜索、监听、TS 内存
  • 让大型项目更流畅

总结
  • folders:一次性打开多个项目
  • files.exclude:左侧隐藏文件
  • search.exclude:搜索不查这些
  • watcherExclude:不监听这些文件(防卡顿)
  • maxTsServerMemory:给 TS 加大内存
  • extensions:团队共享插件

如果你需要,我还能帮你:

  • 优化这个配置
  • 给你生成更干净、更通用的 .code-workspace 模板
  • 解释多项目工作区的优缺点/使用场景

.git/info/exclude 干啥用的

2026-05-26

简单说:它是 Git 项目里「只对你自己生效」的忽略文件,作用和 .gitignore 几乎一样,但不会被提交到 Git 仓库、不会共享给团队成员


核心区别(一看就懂)

文件作用是否提交到仓库是否共享给团队
.gitignore团队通用忽略规则✅ 是✅ 是(所有人都生效)
.git/info/exclude个人本地忽略规则❌ 否❌ 否(只对你自己生效)

什么时候用 .git/info/exclude?

你只需要在自己电脑上忽略不想让团队其他人也跟着忽略的文件,就放这里:

  1. 你本地编辑器生成的临时文件(比如 .idea/.vscode/*.swp
  2. 你个人的测试脚本、本地调试文件
  3. 系统自动生成的垃圾文件(.DS_Store 仅限你自己)
  4. 不想污染公共 .gitignore 的个人配置

怎么用?

  1. 打开项目里的这个文件(路径固定)

    你的项目/.git/info/exclude

    注意:.git 是隐藏文件夹,需要开启显示隐藏文件才能看到

  2. 直接在里面写忽略规则,语法和 .gitignore 完全一样 示例:

    # 我的本地忽略
    .vscode/
    .idea/
    *.log
    temp/
    my-local-test.js
  3. 保存即可生效,不需要提交 Git


重要提醒

  • 它不会被提交:你写的规则只有你自己能用,队友看不到
  • 优先级:和 .gitignore 一起生效,谁忽略都行
  • 不要把团队需要共用的忽略规则写在这里(那是 .gitignore 的职责)

总结

  • .gitignore = 团队共用忽略
  • .git/info/exclude = 你自己本地专用忽略

什么时候用while,什么时候用for循环,尤其是这种算法题,怎么区分呢,比如两数之和和最长无重复子串就是for循环

2026-05-26

这是一个很实用的问题,我来帮你总结一下算法题中 forwhile 的选择规则。

核心判断标准:循环的推进方式是否固定

for 循环的场景

特征:有一个指针/索引在每次迭代中固定前进一步

javascript
for (let i = 0; i < n; i++) { ... }

适用于:

  • 遍历型:两数之和(遍历每个元素去 map 里查)
  • 滑动窗口的右指针:最长无重复子串(right 每次固定 +1,left 在内部按条件跳)
  • 单层扫描:需要逐个处理每个元素

本质:你明确知道"谁在推进循环",且它每轮固定走一步


while 循环的场景

特征:循环的推进方式不固定,或有多个指针在"竞争"推进

javascript
while (条件) {
  // 根据情况决定谁动、怎么动
}

适用于:

  • 双指针对撞:盛最多水的容器(有时 left++,有时 right--,不确定谁动)
  • 归并/合并:合并两个有序数组(两个指针交替前进)
  • 链表操作:不知道长度,走到 null 为止
  • 二分查找leftright 交替收缩

本质:没有一个"主角指针"固定步进,推进逻辑在循环体内动态决定


快速判断口诀

问自己答案选择
有没有一个指针每轮必走一步有 →for
多个指针轮流/条件性前进?是 →while
循环次数能提前确定吗?能 →for
只知道终止条件,不知道走几轮?是 →while

对比你做过的题

题目循环方式原因
两数之和for遍历每个元素,i 固定 +1
最长无重复子串forright 固定 +1,left 在内部跳
三数之和for + while外层 i 固定遍历,内层双指针对撞用 while
盛最多水whileleftright 对撞,不确定谁动

一句话总结

有"主驱动指针"每轮固定走一步 → for;推进逻辑不固定 → while

滑动窗口题之所以用 for,是因为 right 是"主驱动",它每轮必走一步;而 left 只是"被动调整",在循环体内按条件跳。双指针对撞用 while,是因为 leftright 地位平等,每轮只有一个动,谁动取决于条件判断。

Clean Architecture && DDD

2026-05-26

  1. Clean Architecture(整洁架构)

直译:整洁架构

通俗理解:一套软件分层设计思想,核心是业务逻辑(核心)不受外部技术、框架、数据库、接口影响,代码分层清晰、依赖单向、易维护、易测试。

核心特点

  • 圈层结构:领域层 > 应用层 > 接口 / 基础设施层
  • 依赖规则:外层依赖内层,内层绝不依赖外层
  • 业务逻辑独立:换数据库、换前端、换第三方接口,核心代码不用改
  1. Domain-Driven Design (DDD,领域驱动设计)

直译:领域驱动设计

通俗理解:一种面向复杂业务的软件开发方法论,以「业务领域」为核心,而非先想技术框架。

核心要点

  • 先梳理业务、行业规则、术语,再写代码
  • 把真实业务概念(用户、订单、商品、规则)映射成代码模型
  • 擅长解决复杂业务系统(电商、金融、政务、企业系统)

Cocos wx对象

2026-05-19

微信开发者工具的 Console 跑在 WebView (调试器) 进程里,而小游戏代码跑在 JSCore (游戏) 进程里——两个进程的 wx 对象不是同一个!

git status --porcelain

2026-05-19

git status --porcelain

  • Porcelain 本义 = 瓷器 = 漂亮但脆弱 = 给人看
  • Plumbing 本义 = 水管 = 粗糙但耐用 = 给机器用
  • --porcelain 参数 = 例外!专门输出机器能用的稳定格式

蓝牙

2026-05-12

等着被扫 = 外围 主动去扫 = 中心

BLE = Bluetooth Low Energy 中文:低功耗蓝牙

RSSI = Received Signal Strength Indicator 中文:接收信号强度指示

为啥 RSSI 是负数? 因为单位是 dBm(分贝毫瓦) 蓝牙、WiFi 这种无线信号:发射功率是正数,传到你手机里已经衰减得很厉害,功率小于 1 毫瓦,就变成负数了。

npx prettier scripts/generat…

2026-01-19

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

contentHeight 就是 popoverCont…

2026-01-18

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

popover 组件的 placement 取值有 le…

2026-01-17

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;
}

哪些任务交给 AI 最「划算」

2026-01-16

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

两种体验

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

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

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

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

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

落地时我常用三样东西:

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

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

财富就是知识

2026-01-12

财富就是知识 书中的第一个观点,叫做「 财富就是知识 」,这句话大家可能都有听说过,但我们是否对它理解足够? 我们试问一下「 财富就是知识 」,是不是「 知识就是财富 」呢? 虽然看似类似,这两者之间的关系却具有重要的区别。用一个更好理解的方式来看,当我们说「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次你尝试成功了,那就非常强,强过了你提出那个非常确定性解决方案的一次成功。

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

本质是方案设计:优秀的 Prompt 源自对问题的深刻洞…

2026-01-12

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

适合:

2026-01-12

适合:

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

❌ 不适合:

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

如果组件库质量差(类型定义不全、缺少 Demo),再…

2026-01-12

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

某次腾讯文档XX

2026-01-12

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

计算属性只在相关响应式依赖发生改变时它们才会重新求值。这…

2026-01-11

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

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

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

技术优化在业务应用中的稳定性和可靠性:是否能够长时间…

2026-01-10

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

在做中学:不要依赖AI,我们不仅是在打造软件,还在打造个…

2026-01-09

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

明确边界:人是决策者,AI负责执行,不能把思考交给AI!

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

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

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

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

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

  1. 掌握业务灵魂(领域模型),以规范(Spec)为核心资产

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

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

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

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

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