2025-09-30 11:55:55
上周抽空将 GitHub Spec Kit 移植到了 code-pilot, 新的大型项目使用起来体验还不错，就是特别耗 token，不过今天有了转机了 Claude 4.5 发布了
这里不细说了，类似介绍的文章有很多，核心工作原理是让规范成为工程流程的中心。
git clone https://github.com/ysicing/code-pilot.git ~/.claude
cd .claude
cp CLAUDE.md.example CLAUDE.md
记得将模型从 Opus 切到推荐模型 Sonnet 4.5
/spec-kit:specify [你的需求]
# 澄清需求
/spec-kit:clarify
# 后面一直输入 继续 继续 继续 就可以了
新模型确实很能打，没有降智，还便宜。减少了阿谀奉承、欺骗、权力追求和鼓励妄想思维等相关行为
欢迎关注，可以看看我郑再打工每天都在折腾什么。
2025-09-23 23:21:25
已经使用很长一段时间，ClaudeCode 和 Codex 互相调用，简单分享一下。我使用的场景大多数在 ClaudeCode 降智瞎写时，你干不了用 codex 帮你看看吧
如果你的主 AI 编程工具是 Codex，可以在 ~/.codex/config.toml 配置文件中配置一个 Claude Code MCP 服务
[mcp_servers.claude]
command = "claude"
args = ["mcp", "serve"]
配好后打开 Codex，输入 /mcp 就能看到 Claude 的工具了。
使用技巧：
使用claude帮我制定迭代计划保存到plan.md
如果你的主 AI 编程工具是 Claude Code，则可以添加 Codex MCP 服务：
claude mcp add -s user codex-gpt-5 -- codex mcp
添加之后，打开 Claude Code 的 /mcp 命令可以看到 codex 工具
使用技巧：
使用codex基于plan.md完成todo的任务
2025-09-19 21:37:14
物语云筹办的国际站(无需 KYC、中立服务)在今天上线，非常荣幸能作为内测用户，提前体验到物语云的香港产品线(HK BGP Global)。
后台管理面板依旧是和物语云国内站点一样，自主研发 简单易用。
本文测评主要以存储型示例，系统默认为 FNOS，由于测评时间属于晚高峰，跨境且无大陆优化，链路情况仅供参考。
如果打不开或者打开比较慢很正常，目前正在接受洗礼, 官方备货充足，可以错峰购买。
首发循环优惠 5 折, 下面为优惠后价格
每款配置都配备了 1Gbps 的带宽，纯国际线路无大陆优化, 防护峰值 10Gbps
除此之外，还有福利:
以下测评基于 NodeQuality 测试脚本测评，且未使用物语云 DNS 解锁服务
Basic System Information:
---------------------------------
Uptime : 0 days, 9 hours, 41 minutes
Processor : Intel(R) Xeon(R) Platinum 8269CY CPU @ 2.50GHz
CPU cores : 1 @ 2494.140 MHz
AES-NI : ✔ Enabled
VM-x/AMD-V : ✔ Enabled
RAM : 976.7 MiB
Swap : 1024.0 MiB
Disk : 515.0 GiB
Distro : Debian GNU/Linux 12 (bookworm)
Kernel : 6.12.18-trim
VM Type : STANDARD PC (I440FX + PIIX, 1996)
IPv4/IPv6 : ✔ Online / ✔ Online
IPv6 Network Information:
---------------------------------
ISP : Unknown
ASN : AS205548 ZOUTER LIMITED
Location : Hong Kong, Kowloon ()
Country : Hong Kong
fio Disk Speed Tests (Mixed R/W 50/50) (Partition -):
---------------------------------
Block Size | 4k (IOPS) | 64k (IOPS)
------ | --- ---- | ---- ----
Read | 71.93 MB/s (17.9k) | 1.06 GB/s (16.7k)
Write | 72.11 MB/s (18.0k) | 1.07 GB/s (16.7k)
Total | 144.04 MB/s (36.0k) | 2.14 GB/s (33.4k)
| |
Block Size | 512k (IOPS) | 1m (IOPS)
------ | --- ---- | ---- ----
Read | 1.02 GB/s (1.9k) | 1.00 GB/s (984)
Write | 1.07 GB/s (2.0k) | 1.07 GB/s (1.0k)
Total | 2.09 GB/s (4.0k) | 2.08 GB/s (2.0k)
Geekbench 5 Benchmark Test:
---------------------------------
Test | Value
|
Single Core | 794
Multi Core | 789
Full Test | https://browser.geekbench.com/v5/cpu/23794734
SysBench CPU 测试 (Fast Mode, 1-Pass @ 5sec)
---------------------------------
1 线程测试(单核)得分: 1008 Scores
SysBench 内存测试 (Fast Mode, 1-Pass @ 5sec)
---------------------------------
单线程读测试: 20287.46 MB/s
单线程写测试: 17149.31 MB/s
大盘的性能 IO 还是挺满意，秒杀其他石头盘，内测早期测评数据(后面官方放宽了硬盘 I/O 限制)
启动盘：
fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda1):
---------------------------------
Block Size | 4k (IOPS) | 64k (IOPS)
------ | --- ---- | ---- ----
Read | 66.85 MB/s (16.7k) | 89.56 MB/s (1.3k)
Write | 67.00 MB/s (16.7k) | 90.03 MB/s (1.4k)
Total | 133.85 MB/s (33.4k) | 179.60 MB/s (2.8k)
| |
Block Size | 512k (IOPS) | 1m (IOPS)
------ | --- ---- | ---- ----
Read | 179.56 MB/s (350) | 247.14 MB/s (241)
Write | 189.10 MB/s (369) | 263.60 MB/s (257)
Total | 368.66 MB/s (719) | 510.75 MB/s (498)
存储盘:
fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vdb1):
---------------------------------
Block Size | 4k (IOPS) | 64k (IOPS)
------ | --- ---- | ---- ----
Read | 41.38 MB/s (10.3k) | 77.65 MB/s (1.2k)
Write | 41.45 MB/s (10.3k) | 78.06 MB/s (1.2k)
Total | 82.84 MB/s (20.7k) | 155.71 MB/s (2.4k)
| |
Block Size | 512k (IOPS) | 1m (IOPS)
------ | --- ---- | ---- ----
Read | 183.89 MB/s (359) | 241.67 MB/s (236)
Write | 193.66 MB/s (378) | 257.76 MB/s (251)
Total | 377.55 MB/s (737) | 499.44 MB/s (487)
测试 IP: 151.243.229.1
对比其他家优势:
2025-08-21 21:25:27
适用于部署了 PVE9 的 k3s 节点。由于本文属于回忆文，可能存在一些出入，总体流程没问题。
我目前已经将大部分 k3s 节点系统升级到最新的 Debian13 了，最近手头又多了一台杜甫，首先装了 Debian13，部署了 k3s 计算节点，然后观察到节点资源还很富裕，可以跑个 PVE 集群节点。
主要参考 oneclickvirt/pve,直接在 Debian13 上安装 PVE9。中间踩了一个坑，忘记安装前配置 hosts
# 确定能ping，不然后面/etc/pve/local/pve-ssl.key创建失败导致pve没法正常启动
ping $(uname -n)
未部署 PVE 前，k3s 正常工作了很长时间。安装完 PVE 后，部分 POD 开始报错了，本文以 kruise-daemon 为例，一直启动不了直至 CrashLoopBackOff。
查看相关日志后，发现 pod 所在节点审计日志：
[Thu Aug 21 11:52:09 2025] audit: type=1400 audit(1755748328.817:29): apparmor="DENIED" operation="create" class="net" info="failed protocol match" error=-13 profile="cri-containerd.apparmor.d" pid=20287 comm="kruise-daemon" family="unix" sock_type="stream" protocol=0 requested="create" denied="create" addr=none
发现 AppArmor 这位严格的安全管家把你的应用操作给拦下来了。分析一下这个日志，这是一条典型的 AppArmor 安全策略拒绝 (DENIED) 日志。简单来说，系统上的一个名为 kruise-daemon 的程序(运行在容器内)尝试执行一个操作，但被 AppArmor 安全模块阻止了
节选自 AI 分析
[Thu Aug 21 11:09:38 2025] audit: type=1400: 这是日志的时间戳和审计事件类型。
apparmor="DENIED": 核心信息。AppArmor 拒绝了一个操作。AppArmor 是 Linux 内核的一个强制访问控制（MAC）安全模块，它可以将程序限制在一组有限的资源中。
operation="create": 被拒绝的操作是“创建”。
class="net": 操作的类别是网络（net）相关的。
info="failed protocol match": 拒绝的详细原因。程序尝试创建的套接字（socket）的协议类型与 AppArmor 策略文件中允许的协议不匹配。
error=-13: 对应系统错误码 EACCES (Permission denied)，进一步证实是权限问题。
profile="cri-containerd.apparmor.d": 关键信息。触发这个拒绝事件的安全策略文件是 cri-containerd.apparmor.d。这通常是 containerd 容器运行时的默认 AppArmor 配置文件，用于限制所有由 containerd 管理的容器的行为。
pid=48236 comm="kruise-daemon": 执行这个操作的进程是 kruise-daemon，进程 ID 是 48236。kruise-daemon 是 OpenKruise 的一个组件，通常以 DaemonSet 的形式运行在 Kubernetes 的每个节点上，负责一些节点级的增强功能。
family="unix": 网络套接字的类型是 Unix Domain Socket (UDS)，这是一种用于同一台主机上进程间通信的机制，而非跨主机的 TCP/IP 网络。
sock_type="stream": 套接字的类型是流式套接字（stream），类似于 TCP。
protocol=0: 使用的协议号是 0（默认协议）。
一句话总结： 运行在 containerd 容器中的 kruise-daemon 进程试图创建一个 Unix 域流式套接字（Unix Domain Stream Socket），但是 Kubernetes 节点上为容器配置的默认 AppArmor 安全策略 (cri-containerd.apparmor.d) 不允许这个操作。
这通常意味着 kruise-daemon 需要通过 Unix Socket 与节点上的其他服务（例如 Docker daemon、CNI 插件或其他 agent）进行通信，但默认的安全策略为了保证容器的隔离性，限制了这类“高级”或“特殊”的网络操作。
需要查看 AppArmor 当前在内核中加载了哪些 Profile
apparmor_status 或者aa-status
# 结果(这个是我调整后的，默认 cri-containerd.apparmor.d也是强制模式)
apparmor module is loaded.
8 profiles are loaded.
7 profiles are in enforce mode.
/usr/bin/lxc-copy
/usr/bin/lxc-start
docker-default
lxc-container-default
lxc-container-default-cgns
lxc-container-default-with-mounting
lxc-container-default-with-nesting
1 profiles are in complain mode.
cri-containerd.apparmor.d
0 profiles are in prompt mode.
0 profiles are in kill mode.
0 profiles are in unconfined mode.
1 processes have profiles defined.
0 processes are in enforce mode.
1 processes are in complain mode.
/kruise-daemon (31408) cri-containerd.apparmor.d
0 processes are in prompt mode.
0 processes are in kill mode.
0 processes are unconfined but have a profile defined.
0 processes are in mixed mode.
默认 /etc/apparmor.d/ 目录下是没有这个的，是 containerd 启动时加载到内核的。针对这种情况下，最好的办法是覆盖它。 我们可以在标准路径 /etc/apparmor.d/ 下创建一个同名的文件。当 AppArmor 服务重载配置时，它会优先使用磁盘上的文件来覆盖内存中已加载的同名 Profile
这里简单记录一下，没那么简单。
在 /etc/apparmor.d/ 目录下创建一个新文件，名字就叫 cri-containerd.apparmor.d
cat > /etc/apparmor.d/cri-containerd.apparmor.d <<EOF
# AppArmor Profile for cri-containerd.apparmor.d
# SYNTAX: AppArmor 4.1 (for Debian 13+)
#include <tunables/global>
# 声明我们使用的是新的 v4 语法，这非常重要！
abi <abi/4.0>,
profile cri-containerd.apparmor.d flags=(attach_disconnected, complain, mediate_deleted) {
#include <abstractions/base>
#include <abstractions/nameservice>
# 授予容器运行时所需的大部分 POSIX capabilities
capability,
# 拒绝直接写内核和内存等危险操作
deny /dev/mem w,
deny /dev/kmem w,
# 允许通用的网络操作 (TCP/IP 等)
# 在新语法中，这个规则不包含 unix socket
network,
# === AppArmor 4.x 关键修改 ===
# 使用新的、独立的 unix socket 规则族
# 直接允许创建、连接、监听、发送、接收 stream 类型的 unix socket
unix (create, connect, listen, accept, send, receive) type=stream,
# 允许挂载相关的操作
mount options=(ro, nosuid, nodev, noexec, remount, bind),
remount,
# 允许容器运行时需要的一些基本文件访问
/dev/urandom r,
/sys/devices/system/cpu/online r,
/sys/fs/cgroup/ r,
/sys/fs/cgroup/** r,
# 拒绝修改 AppArmor 自身，增强安全性
deny /sys/kernel/security/apparmor/** w,
}
EOF
重新加载 AppArmor 配置，让我们的新文件生效
# -r 表示 replace，会替换掉内存中已有的同名 profile
apparmor_parser -r /etc/apparmor.d/cri-containerd.apparmor.d
再次运行 aa_status，确保 Profile 仍然在加载状态。然后尝试重建一下出问题的那个 kruise-daemon Pod，发现还是会 Deny，换了一个新错
了[Thu Aug 21 12:07:43 2025] audit: type=1400 audit(1755749262.720:42): apparmor="DENIED" operation="open" class="file" profile="cri-containerd.apparmor.d" name="/run/secrets/kubernetes.io/serviceaccount/..2025_08_21_04_07_36.2733297639/token" pid=28709 comm="kruise-daemon" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
同上流程，是不是改一下配置文件就可以，是的, 截取了新增的地方如下
/sys/fs/cgroup/** r,
# --- 本次新增规则 ---
# 允许 Pod 读取其 Service Account Token，以便与 K8s API Server 通信
"/run/secrets/kubernetes.io/serviceaccount/**" r,
# 拒绝修改 AppArmor 自身，增强安全性
deny /sys/kernel/security/apparmor/** w,
}
作为暴躁小伙，这样多麻烦，反正自己的环境应该也没啥大问题, 一梭子解决，观察者模式, 只需记录，不会拦截
aa-complain /etc/apparmor.d/cri-containerd.apparmor.d
其实到这里，问题基本解决了，但是没彻底解决。可以根据审计日志来完善，收集全部权限需求，一次性构建完整的 Profile，然后切换回 Enforce
官方这里确实好像有 BUG，事后没搜到了。
希望这次的分享能帮到大家！觉得有用的话，别忘了点赞、在看、分享三连哦！
2025-08-12 21:38:59
这是最近新出的功能状态栏配置, 要求版本至少是 1.0.72, 官方文档已经很详细，具体可以参考 claude-code/statusline
为 Claude Code 创建自定义状态栏以显示上下文信息
通过自定义状态栏让 Claude Code 成为您专属的工具，该状态栏显示在 Claude Code 界面底部，类似于终端提示符（PS1）在 Oh-my-zsh 等 shell 中的工作方式。
官方给了两种方式:
另外我的 code-pilot 默认也集成了基础版本的，具体可以参考 settings.example
"statusLine": {
"type": "command",
"command": "~/.claude/scripts/statusline.sh",
"padding": 0
}
不过，本文主要将如何使用佬友写的 CCometixLine
有兴趣的可以查阅佬友的原文 Claude Code StatusLine | 小工具 大用处
由于我个人的习惯, 二进制放 bin，脚本放 scripts 目录下
20:26 ➜ .claude git:(master) tree -L 1
.
├── assets
├── bin
├── scripts
├── settings.json
└── CLAUDE.md
11 directories, 11 files
项目地址: CCometixLine
涉及到非中文字体安装, 主要是 CCometixLine 图标依靠 Nerd Font
brew tap laishulu/homebrew
brew install font-meslo-lg-nerd-font
佬友推荐了:
安装完成后设置 iTerm2 的字体，主要设置我勾选的那个就可以使图标生效
配置也比较简单, 从 github 下载对应的二进制压缩包，解压放到对应的目录即可，检查一下权限，需要有执行权限
mkdir -p ~/.claude/bin
wget https://github.com/Haleclipse/CCometixLine/releases/latest/download/ccline-macos-arm64.tar.gz
tar -xzf ccline-macos-arm64.tar.gz
cp ccline ~/.claude/bin/
chmod +x ~/.claude/bin/ccline
然后 settings.json 配置如下:
cat settings.json | jq .statusLine
{
"type": "command",
"command": "~/.claude/bin/ccline",
"padding": 0
}
佬友提供的,可能受限于编译环境，可能提示 glibc 问题。现象就是配置了不生效，可以使用 .claude/bin/ccline -V 测试，如果能提示版本就没问题。
这里我也提供一个在 Debian13(12)都可以运行
https://c.ysicing.net/oss/tiga/linux/amd64/ccline-linux-amd64
除了这些外，还可以使用 ccusage, 可以实时看到今天的总费用、当前活跃的 5 小时区块费用 & 剩余时间、实时消耗速率
{
"statusLine": {
"type": "command",
"command": "bun x ccusage statusline"
}
}
2025-08-10 21:32:38
大家好，今天来给大家安利一个超级黑科技工具——基于 Claude Code 多智能体工作流系统！这个工作流，它不是简单的代码生成器，而是将你的开发流程从手动命令链升级成自动化专家团队。想象一下，原本需要你一步步监督代码的编写、测试、优化，现在交给一群 AI 智能体分工协作，质量把控还自动过关，简直是福音！如果你是开发者、产品经理，或者对 AI 辅助编程感兴趣，强烈安利。咱们一步步来拆解这个系统的魅力，看看它如何让你的工作流变得更高效、更智能。
https://github.com/ysicing/code-pilot
仓库 README 文件或者 guide 指南文件也是非常详细的，也会随着项目迭代而更新，本文也是根据相关内容撰写而来，有兴趣可以尝试一下
简单来说，这个系统是基于 Anthropic 的 Claude Code 构建的开发工具。它将传统的开发过程（如需求分析、代码实现、质量审查、测试、调试）拆分成多个专业 AI 智能体，每个智能体专注于一个领域，避免了万能 AI 带来的泛化问题
系统内置了 14 个专家智能体，比如：
它不是孤立的，而是无缝集成 Claude Code 命令行(如 /ask、/code、/test），让整个流程像流水线一样顺畅。
一开始想用 agents 和 commands 子目录功能，使用 znb 区分自定义命令，避免重复，不过好在放弃了。
这个工作流不是吹牛，它的设计直接解决了开发中的痛点，让我来列举几个亮点：
总之一句话，让开发从监督密集型转向 自动化专家型，特别适合 Web 应用、DevOps 等场景。
举个例子：某系统登录支持 LDAP，原本可能花半天，现在用 /requirements-pilot 命令，几分钟就搞定从用户需求到研发需求、拆迭代、编写代码、测试、预发布检查全流程。
最大的门槛是如何稳定使用 Claude Code
安装和使用超简单，别担心，这个系统安装门槛低，提供了详细指南。咱们一步步来。
支持用户级或项目级安装，本人推荐使用用户级安装使用
先安装 Claude Code CLI，通过 npm 全局安装：
npm install -g @anthropic-ai/claude-code
然后检查版本：
claude --version
# 本文时版本为1.0.72
1.0.72 (Claude Code)
如果你已有 .claude，先重命名你的
mv ~/.claude ~/.claude-old
克隆到 ~/.claude 目录
git clone https://github.com/ysicing/code-pilot ~/.claude
已有 .claude 的，你可以根据 ~/.claude/.gitignore 内容将 ~/.claude-old 内的目录或者文件同步到 ~/.claude
根据自己的需求，可以将 CLAUDE.md.example 复制一份重命名为 CLAUDE.md, 作为全局 AI 工作流指导文件，大方针；
最后，需要根据自己的实际情况配置了，仅适用于 macOS
{
"$schema": "https://json.schemastore.org/claude-code-settings.json",
"env": {
"ANTHROPIC_AUTH_TOKEN": "token",
"ANTHROPIC_BASE_URL": "url",
"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1",
"CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR": "true",
"CLAUDE_LANGUAGE": "zh"
},
"includeCoAuthoredBy": false,
"permissions": {
"allow": [
],
"deny": [
"Bash(rm -rf:*)",
"Bash(rmdir:*)"
]
},
"hooks": {
"Notification": [
{
"matcher": "*",
"hooks": [
{
"type": "command",
"command": "~/.claude/scripts/show-notification.sh"
}
]
}
],
"Stop": [
{
"matcher": "*",
"hooks": [
{
"type": "command",
"command": "~/.claude/scripts/check-continue.sh"
},
{
"type": "command",
"command": "~/.claude/scripts/task-completed.sh"
}
]
}
]
},
"feedbackSurveyState": {
"lastShownTime": 1754092908693
}
}
重点内容在 hooks 里，是等待指示和完成的通知，默认使用的 macOS 自带工具实现。
示例， 更多提示音可以查看 assets 目录下文件，也可以自定义(示例提示音使用 fish.audio 生成)
# 等待提示
afplay assets/49-confirm.mp3 -v 1
# 完成提示音
afplay assets/49-perfect.mp3 -v 1
# 鸽鸽
afplay assets/cxk-v1-perfect.mp3
另外还提供了多种模式，如需求驱动、问题驱动、质量优先，由于流程不太适合公开分享，建议大家可以拿自己的项目实际跑一跑，用过我这套工作流的都说好。
效率翻倍，质量更稳
本套流程我已经跑了差不多两周了，效率大大的提升，任何需求一来，/requirements-pilot 基本一梭子就解决了
快来试试，AI 开发新时代已来！Claude Code 多智能体工作流系统绝对是 2025 年开发者的必备神器！它不只是工具，更像是你的 AI 团队伙伴。基于 ysicing/code-pilot 赶紧去试用一下吧，5 分钟就能上手。
本项目基于 myclaude 进行二次迭代，在此基础上实现了重大增强和创新。我们衷心感谢：
特别感谢与 Claude 的持续合作，使得复杂的多智能体工作流系统和质量门控自动化成为可能。