惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Engineering at Meta
Engineering at Meta
Cloudbric
Cloudbric
云风的 BLOG
云风的 BLOG
A
About on SuperTechFans
The GitHub Blog
The GitHub Blog
IT之家
IT之家
F
Full Disclosure
B
Blog RSS Feed
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Hugging Face - Blog
Hugging Face - Blog
B
Blog
H
Help Net Security
The Cloudflare Blog
Recorded Future
Recorded Future
P
Proofpoint News Feed
P
Proofpoint News Feed
C
Cisco Blogs
T
Tailwind CSS Blog
P
Palo Alto Networks Blog
D
Docker
爱范儿
爱范儿
Know Your Adversary
Know Your Adversary
博客园 - 聂微东
D
Darknet – Hacking Tools, Hacker News & Cyber Security
Y
Y Combinator Blog
雷峰网
雷峰网
AWS News Blog
AWS News Blog
D
DataBreaches.Net
博客园 - 司徒正美
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
博客园 - Franky
C
Cybersecurity and Infrastructure Security Agency CISA
Blog — PlanetScale
Blog — PlanetScale
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
Latest news
Latest news
Google DeepMind News
Google DeepMind News
Martin Fowler
Martin Fowler
MongoDB | Blog
MongoDB | Blog
C
CERT Recently Published Vulnerability Notes
阮一峰的网络日志
阮一峰的网络日志
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
C
CXSECURITY Database RSS Feed - CXSecurity.com
酷 壳 – CoolShell
酷 壳 – CoolShell
C
Cyber Attacks, Cyber Crime and Cyber Security
腾讯CDC
小众软件
小众软件
G
Google Developers Blog
Hacker News - Newest:
Hacker News - Newest: "LLM"
Scott Helme
Scott Helme
O
OpenAI News

博客园 - 我才是银古

第16章:常见问题、排错与最佳实践 第15章:扩展生态、MCAD 与外部集成 第12章:实战案例:机械结构与 3D 打印零件 第14章:构建、测试、调试与贡献流程 第13章:OpenSCAD 源码架构与核心执行流程 第11章:预览、渲染、网格精度与性能优化 第09章:列表推导、递归与算法建模 第08章:参数化零件库与复用设计 第10章:导入导出、命令行与自动化 第06章:CSG 布尔建模方法 第07章:二维图形、拉伸、旋转与投影 第05章:基础几何、坐标系与变换 第04章:参数、变量、函数、模块与作用域 OpenSCAD 教程目录 第03章:OpenSCAD 语言基础 第02章:安装、环境配置与开发工作流 第01章:OpenSCAD 项目全景与学习路线 第02章:源码获取、编译与开发环境配置 第01章:OCCT项目全景与学习路线 第18章:二次开发实战与综合案例 第17章:与 Qt VTK Python pythonOCC 生态集成 第18章:综合实战案例 第17章:数据交换与协同 第16章:源码架构与二次开发 第15章:插件与自定义工作台开发 第14章:Python脚本宏与自动化 第13章:FEM仿真分析 第12章:CAM数控加工 第11章:SurfaceMesh与逆向工程 第10章:Draft二维绘图与BIM建筑 第09章:工程图TechDraw 第07章:参数化表达式与Spreadsheet 第08章:装配设计Assembly 第06章:Part工作台与几何内核 第05章:PartDesign实体特征建模 第04章:草图Sketcher约束建模 第02章:安装版本与工作环境配置 第03章:界面工作台与基础操作 第01章:项目全景与学习路线 第十二章:插件开发、研究功能与最佳实践 第十章:定时任务与自动化(Cron) 第七章:技能、记忆与自学习闭环 第八章:MCP 集成与上下文文件 第六章:工具系统与终端后端 第五章:模型供应商与配置体系 Hermes Agent 教程目录 第十一章:语音、视觉、浏览器与子代理协作 第四章:CLI/TUI 与会话管理 第十二章:学习路线、实战方案与最佳实践 第十一章:源码结构、开发调试与插件开发 第十章:自动化、远程访问、日志与排障 第九章:Control UI、节点、Canvas 与语音能力 第七章:工具、技能、插件与能力扩展 第八章:安全模型、访问控制与沙箱实践 第六章:Agent 工作区、会话与多智能体路由 第五章:多通道消息接入与聊天平台配置 第四章:配置体系、模型接入与认证管理 第三章:Gateway 架构、协议与运行机制 第二章:安装、环境准备与快速上手 第一章:OpenClaw 项目概览与核心定位 oh-my-openagent 教程目录 09-命令模型回退与配置参考 10-实战案例最佳实践与故障排除 05-工作模式-Ultrawork-Prometheus-Atlas 08-Hooks与MCP系统 06-Category与Skill系统 07-核心工具链 04-智能体全景详解 03-安装与环境配置 02-整体架构与多模型编排机制 01-项目简介与核心理念 01-项目概览与学习路线 02-安装部署与工具适配 03-Skill机制与using-superpowers 05-TDD系统化调试与完成前验证 04-需求澄清方案设计与计划编写 07-并行智能体子智能体与Git-Worktree 第六章:代码审查、反馈处理与分支收尾 09-MCP构建工作流执行与自定义Skill 第23章:FreeCAD-Python-API Clipper2 C# 源码解读教程 第19章:PolyTree 多边形树结构 第20章:实际应用与最佳实践 第18章:Minkowski 和与差 第17章:RectClip 矩形裁剪优化 第16章:ClipperOffset 偏移类详解 第15章:填充规则详解 第14章:布尔运算执行流程 第13章:ClipperD 浮点裁剪类 第11章:OutRec 与 OutPt 输出结构 第9章:Active 活动边结构 第10章:Vertex 顶点与 LocalMinima 局部极小值 第12章:Clipper64 裁剪类详解 第7章:高精度运算与128位整数 第8章:ClipperBase 基类详解 第5章:枚举类型与常量定义 第6章:InternalClipper 内部工具类 第2章:核心数据结构 - Point64、PointD 第3章:路径与多边形表示 - Path64、PathD、Paths64、PathsD 第4章:矩形边界 - Rect64、RectD
08-中国特色Skills与本土团队落地
我才是银古 · 2026-05-04 · via 博客园 - 我才是银古

第八章:中国特色 Skills 与本土团队落地

8.1 为什么需要中国特色 Skills

英文上游 superpowers 解决的是通用 AI 编程工作流问题,但中文团队还有一些额外痛点:

  • 代码审查要兼顾专业性和沟通文化。
  • Git 平台可能是 Gitee、Coding、极狐 GitLab、CNB,而不是 GitHub。
  • Commit Message 需要中文可读,同时兼容 Conventional Commits 工具链。
  • 中文技术文档需要处理中英混排、标点、术语和机翻味。
  • 国内团队常用企业微信、钉钉、禅道、TAPD、Coding 等协作系统。

superpowers-zh 新增的中国特色 Skills 正是为这些场景设计。

8.2 chinese-code-review:中文代码审查

这个 Skill 的核心原则是:用「建议」代替「命令」,用「提问」代替「否定」,但绝不因为面子放过 Bug。

推荐使用优先级标记:

  • [必须修复]:安全漏洞、数据丢失、并发错误、逻辑错误。
  • [建议修改]:性能问题、可维护性问题、缺少校验。
  • [仅供参考]:命名、风格、替代方案。
  • [问题]:不确定作者意图,需要解释。

示例:

[必须修复] 并发安全问题

这里的 map 会在多个 goroutine 中同时读写,可能触发 panic。
建议加 sync.RWMutex,或改用 sync.Map。可以用 -race 跑测试复现。

这种表达既清楚说明严重性,又给出原因和建议。

8.3 中文审查中的表达平衡

需要避免两个极端:

过度客气

不知道我理解得对不对,这里好像可能有一点点问题……

这种写法会让作者不知道是否必须修。

过度强硬

这里写错了,必须改。

这种写法虽然直接,但容易引发防御心理。

推荐写法:

[建议修改] 这里可能存在空值风险。
如果 user.Profile 为 nil,第 42 行会 panic。建议在进入分支前做空值判断,或在查询层保证 Profile 必填。

8.4 chinese-git-workflow:国内 Git 平台适配

该 Skill 对比了 Gitee、Coding.net、极狐 GitLab、CNB 和 GitHub,并给出不同团队规模适用的工作流。

主干开发

适合 2-8 人小团队、自动化测试完善、迭代快:

  • main 始终可发布。
  • 功能分支短命,1-2 天内合回。
  • 用 Feature Flag 隐藏未完成功能。

Git Flow

适合中大团队、固定发布节奏、需要多版本维护:

  • main 代表生产环境。
  • develop 代表开发主线。
  • release 分支用于发布稳定。
  • hotfix 从 main 拉出。

国内常用简化流程

适合多数中小团队:

  • main 受保护,对应生产。
  • dev 对应测试环境,自动部署。
  • 功能分支从 dev 拉出,合回 dev。
  • dev 测试通过后合并 main 发布。

8.5 分支命名规范

推荐:

feat/user-login
feat/TAPD-12345-order-refund
fix/payment-callback
hotfix/v2.0.1
release/v2.1.0
dev/zhangsan/feat-login

规则:

  1. 使用小写英文和短横线。
  2. 前缀表示类型:feat/fix/hotfix/release/
  3. 如有任务编号,放入分支名。
  4. 名称能看出目的即可,不要过长。

8.6 chinese-commit-conventions:中文提交规范

该 Skill 基于 Conventional Commits 1.0.0,保留英文 type,scope 和 description 使用中文。

格式:

<type>(<scope>): <subject>

<body>

<footer>

示例:

feat(用户模块): 添加手机号一键登录功能

- 接入运营商一键登录 SDK
- 支持移动、联通、电信三网
- 登录失败自动降级到短信验证码

Closes #128

常用类型:

type 含义
feat 新功能
fix Bug 修复
docs 文档
style 格式,不影响逻辑
refactor 重构
perf 性能优化
test 测试
chore 工具、依赖、杂项
ci CI/CD
revert 回滚

8.7 Commit Message 的落地工具

团队可以用 commitlint + husky 强制规范:

npm install -D @commitlint/cli @commitlint/config-conventional husky

关键配置思路:

  • 允许中文 subject。
  • 放宽 header 长度,因为中文宽度不同。
  • 关闭 subject-case
  • 保留 type 枚举。
  • body 用中文说明背景、方案和影响范围。

规范要靠工具,而不是靠每个人自觉。

8.8 chinese-documentation:中文技术文档规范

这个 Skill 解决中文技术文档最常见的问题:

  • 中英文之间没有空格。
  • 中文和数字之间没有空格。
  • 全角半角标点混用。
  • 技术术语过度翻译。
  • 句子有机翻味。
  • 一大段文字缺少结构。

核心规则:

使用 Git 管理代码,配合 Jenkins 实现持续集成。
本次更新包含 3 个功能和 12 个 Bug 修复。
文件大小不超过 5 MB,CPU 使用率低于 80%。

中文语境使用全角标点,代码、命令和纯英文内容使用半角标点。

8.9 术语翻译原则

保留英文:

  • 专有名词:React、Kubernetes、Redis、MySQL。
  • 行业缩写:API、SDK、CLI、ORM、CI/CD。
  • 命令和代码:npm installgit commit
  • 协议和标准:HTTP、JSON、REST。
  • 没有公认中文翻译的术语:middleware、debounce、throttle。

翻译中文:

  • 有公认翻译的概念:数据库、服务器、浏览器。
  • 描述性短语:版本控制、负载均衡。
  • 标题和章节名尽量中文,必要时保留英文术语。

首次出现可写中英对照:

本系统使用消息队列(Message Queue)实现异步通信。

8.10 中文文档结构建议

好的中文技术文档应结构化:

# 标题

## 背景

说明为什么需要这篇文档。

## 快速开始

给出最短可运行路径。

## 核心概念

解释读者必须理解的模型。

## 操作步骤

按步骤说明如何使用。

## 常见问题

列出错误、原因和解决方式。

## 检查清单

提供发布或交付前自查项。

不要用长段落堆叠所有信息。能用列表、表格、步骤和代码块表达的内容,应优先结构化。

8.11 团队落地顺序

推荐按以下顺序落地:

  1. 文档规范先行。 统一中英混排、标题、表格、API 文档格式。
  2. 提交规范工具化。 配置 commitlint、husky 或 PR 检查。
  3. 代码审查分级。 在团队约定中明确 [必须修复] 等标签。
  4. Git 流程标准化。 根据平台选择 main/dev、Git Flow 或主干开发。
  5. AI 指令固化。 在项目自定义指令中要求 AI 遵循这些 Skills。

8.12 本章小结

中国特色 Skills 不是把英文规则翻译成中文,而是把中文团队真实协作环境纳入 AI 编程流程。它们能让 superpowers-zh 从个人效率工具变成团队工程规范的一部分。