Sync: add project management and xr notes
This commit is contained in:
334
Project/fonrey/PRD/登录管理/找回流程图.drawio
Normal file
334
Project/fonrey/PRD/登录管理/找回流程图.drawio
Normal file
@@ -0,0 +1,334 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<mxfile host="app.diagrams.net" modified="2026-04-25T00:00:00.000Z" agent="OpenCode" version="21.0.0">
|
||||
|
||||
<!-- ============================================================
|
||||
5.4.1 找回用户名流程
|
||||
============================================================ -->
|
||||
<diagram id="recover-username" name="5.4.1 找回用户名流程">
|
||||
<mxGraphModel dx="1200" dy="800" grid="1" gridSize="10" guides="1" tooltips="1"
|
||||
connect="1" arrows="1" fold="1" page="1" pageScale="1"
|
||||
pageWidth="850" pageHeight="1100" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0" />
|
||||
<mxCell id="1" parent="0" />
|
||||
|
||||
<!-- Title -->
|
||||
<mxCell id="t1" value="5.4.1 找回用户名流程" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=16;fontStyle=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="175" y="20" width="500" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Start -->
|
||||
<mxCell id="u1" value="用户点击「忘记用户名」" style="ellipse;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;fontStyle=1;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="275" y="80" width="300" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Decision: Is email format valid? -->
|
||||
<mxCell id="u2" value="展示「找回用户名」页面
（邮箱输入框 + 发送按钮）" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="250" y="170" width="350" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- User inputs email -->
|
||||
<mxCell id="u3" value="用户输入邮箱并点击「发送」" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#f5f5f5;strokeColor=#666666;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="250" y="260" width="350" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Decision: Email format valid? -->
|
||||
<mxCell id="u4" value="邮箱格式校验通过？" style="rhombus;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="275" y="350" width="300" height="70" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Format invalid -->
|
||||
<mxCell id="u5" value="提示「请输入有效的邮箱地址」" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#f8cecc;strokeColor=#b85450;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="620" y="360" width="220" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Backend query -->
|
||||
<mxCell id="u6" value="服务端查询邮箱是否绑定账号
（不向前端返回查询结果）" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#f5f5f5;strokeColor=#666666;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="250" y="470" width="350" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Unified response to frontend -->
|
||||
<mxCell id="u7" value="统一响应前端：
「如该邮箱已绑定账号，您将收到邮件」
发送按钮进入 60 秒倒计时" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="250" y="580" width="350" height="70" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Decision: Email exists? -->
|
||||
<mxCell id="u8" value="邮箱已绑定 Tenant Admin 账号？" style="rhombus;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="630" y="475" width="240" height="70" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Email found: send email -->
|
||||
<mxCell id="u9" value="后台：异步发送邮件
（包含用户名、发送时间）" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="640" y="580" width="220" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Email not found: silent -->
|
||||
<mxCell id="u10" value="后台：静默处理
（不发送邮件，不报错）" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#f5f5f5;strokeColor=#666666;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="640" y="660" width="220" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Rate limit check -->
|
||||
<mxCell id="u11" value="同一邮箱 1 小时内已发送 ≥ 3 次？" style="rhombus;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="630" y="700" width="240" height="70" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Rate limit exceeded -->
|
||||
<mxCell id="u12" value="拒绝发送
（达到频率上限）" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#f8cecc;strokeColor=#b85450;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="900" y="715" width="160" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- User receives email -->
|
||||
<mxCell id="u13" value="用户查收邮件，获取用户名" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#f5f5f5;strokeColor=#666666;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="640" y="810" width="220" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Return to login -->
|
||||
<mxCell id="u14" value="点击「返回登录」
回到登录界面" style="ellipse;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="275" y="700" width="300" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Edges -->
|
||||
<mxCell id="e1" edge="1" source="u1" target="u2" parent="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e2" edge="1" source="u2" target="u3" parent="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e3" edge="1" source="u3" target="u4" parent="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e4" value="否" edge="1" source="u4" target="u5" parent="1">
|
||||
<mxGeometry relative="1" as="geometry"><Array as="points"><mxPoint x="620" y="385" /></Array></mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="e5" value="" edge="1" source="u5" target="u3" parent="1">
|
||||
<mxGeometry relative="1" as="geometry"><Array as="points"><mxPoint x="730" y="285" /></Array></mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="e6" value="是" edge="1" source="u4" target="u6" parent="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e7" edge="1" source="u6" target="u7" parent="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e8" edge="1" source="u6" target="u8" parent="1">
|
||||
<mxGeometry relative="1" as="geometry"><Array as="points"><mxPoint x="600" y="500" /><mxPoint x="630" y="510" /></Array></mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="e9" value="是" edge="1" source="u8" target="u11" parent="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e10" value="否（普通员工邮箱或不存在）" edge="1" source="u8" target="u10" parent="1">
|
||||
<mxGeometry relative="1" as="geometry"><mxPoint x="760" y="660" as="targetPoint" /></mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="e11" value="否（未超限）" edge="1" source="u11" target="u9" parent="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e12" value="是（超过 3 次）" edge="1" source="u11" target="u12" parent="1">
|
||||
<mxGeometry relative="1" as="geometry"><Array as="points"><mxPoint x="900" y="735" /></Array></mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="e13" edge="1" source="u9" target="u13" parent="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="e14" edge="1" source="u13" target="u14" parent="1">
|
||||
<mxGeometry relative="1" as="geometry"><Array as="points"><mxPoint x="750" y="835" /><mxPoint x="425" y="835" /><mxPoint x="425" y="750" /></Array></mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="e15" edge="1" source="u7" target="u14" parent="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
</diagram>
|
||||
|
||||
<!-- ============================================================
|
||||
5.4.2 找回密码流程
|
||||
============================================================ -->
|
||||
<diagram id="recover-password" name="5.4.2 找回密码流程">
|
||||
<mxGraphModel dx="1200" dy="800" grid="1" gridSize="10" guides="1" tooltips="1"
|
||||
connect="1" arrows="1" fold="1" page="1" pageScale="1"
|
||||
pageWidth="850" pageHeight="1300" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0" />
|
||||
<mxCell id="1" parent="0" />
|
||||
|
||||
<!-- Title -->
|
||||
<mxCell id="title" value="5.4.2 找回密码流程" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=16;fontStyle=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="175" y="20" width="500" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- ===== STEP 1 Header ===== -->
|
||||
<mxCell id="step1hdr" value="步骤一：身份验证" style="text;html=1;strokeColor=none;fillColor=#dae8fc;align=left;verticalAlign=middle;whiteSpace=wrap;rounded=1;fontSize=13;fontStyle=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="60" y="65" width="730" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Start -->
|
||||
<mxCell id="p1" value="用户点击「忘记密码」" style="ellipse;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;fontStyle=1;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="275" y="115" width="300" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Show form -->
|
||||
<mxCell id="p2" value="展示「找回密码」页面（Stepper）
步骤一：用户名 + 绑定邮箱输入框" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="225" y="200" width="400" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- User submits -->
|
||||
<mxCell id="p3" value="用户输入用户名 + 邮箱，点击「下一步」" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#f5f5f5;strokeColor=#666666;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="225" y="300" width="400" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Backend verification -->
|
||||
<mxCell id="p4" value="服务端校验用户名与邮箱是否匹配" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#f5f5f5;strokeColor=#666666;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="225" y="390" width="400" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Unified response -->
|
||||
<mxCell id="p5" value="统一响应前端：
「如信息匹配，重置链接将发送至您的邮箱」" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="225" y="480" width="400" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Decision: Match? -->
|
||||
<mxCell id="p6" value="用户名与邮箱匹配？" style="rhombus;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="650" y="395" width="220" height="70" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Rate limit check -->
|
||||
<mxCell id="p7" value="同一账号 1 小时内已发 ≥ 3 次？" style="rhombus;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="650" y="490" width="220" height="70" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Matched: generate token -->
|
||||
<mxCell id="p8" value="生成加密 Token
（secrets.token_urlsafe(32)，有效期 30 分钟）
异步发送重置邮件" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="650" y="590" width="240" height="70" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- No match: silent -->
|
||||
<mxCell id="p9" value="不匹配：静默处理
（不发邮件，不报错）" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#f5f5f5;strokeColor=#666666;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="900" y="405" width="180" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Rate limit exceeded -->
|
||||
<mxCell id="p10" value="已超频率上限
静默处理" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#f8cecc;strokeColor=#b85450;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="900" y="505" width="160" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- ===== STEP 2 Header ===== -->
|
||||
<mxCell id="step2hdr" value="步骤二：用户点击邮件重置链接" style="text;html=1;strokeColor=none;fillColor=#d5e8d4;align=left;verticalAlign=middle;whiteSpace=wrap;rounded=1;fontSize=13;fontStyle=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="60" y="690" width="730" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- User clicks link -->
|
||||
<mxCell id="p11" value="用户点击邮件中的重置链接" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#f5f5f5;strokeColor=#666666;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="275" y="740" width="300" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Validate token -->
|
||||
<mxCell id="p12" value="服务端校验 Token 有效性
（is_used=False AND expires_at 未过期）" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#f5f5f5;strokeColor=#666666;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="250" y="830" width="350" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Token decision -->
|
||||
<mxCell id="p13" value="Token 有效？" style="rhombus;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="300" y="930" width="250" height="70" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Invalid token -->
|
||||
<mxCell id="p14" value="提示「链接已过期或已使用，请重新申请」
提供「重新申请」按钮（跳回步骤一）" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#f8cecc;strokeColor=#b85450;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="620" y="940" width="260" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- ===== STEP 3 Header ===== -->
|
||||
<mxCell id="step3hdr" value="步骤三：输入并提交新密码" style="text;html=1;strokeColor=none;fillColor=#fff2cc;align=left;verticalAlign=middle;whiteSpace=wrap;rounded=1;fontSize=13;fontStyle=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="60" y="1030" width="730" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Show reset form -->
|
||||
<mxCell id="p15" value="展示「重置密码」表单
（新密码 + 确认新密码 + 密码强度指示）" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="250" y="1080" width="350" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- User submits new password -->
|
||||
<mxCell id="p16" value="用户输入新密码并提交" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#f5f5f5;strokeColor=#666666;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="275" y="1180" width="300" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Complexity check -->
|
||||
<mxCell id="p17" value="密码复杂度校验
（≥8位，含字母+数字，两次一致）" style="rhombus;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="275" y="1265" width="300" height="80" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Complexity fail -->
|
||||
<mxCell id="p18" value="实时提示不满足的规则
（逐条红色 ✗ / 绿色 ✓ 视觉指引）" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#f8cecc;strokeColor=#b85450;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="640" y="1275" width="240" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- History check -->
|
||||
<mxCell id="p19" value="历史密码校验
（不得与最近 3 次历史密码相同）" style="rhombus;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="275" y="1380" width="300" height="80" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- History fail -->
|
||||
<mxCell id="p20" value="提示「不得与最近 3 次密码相同」" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#f8cecc;strokeColor=#b85450;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="640" y="1395" width="240" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Success: update password -->
|
||||
<mxCell id="p21" value="✅ 校验通过：
① 更新密码（PBKDF2+SHA256 哈希存储）
② is_initial_password = False
③ 清除该账号所有有效 Session
④ 标记 Token 为 is_used = True" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="225" y="1500" width="400" height="100" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- End -->
|
||||
<mxCell id="p22" value="跳转登录界面
提示「密码已重置，请使用新密码登录」" style="ellipse;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;fontSize=12;" vertex="1" parent="1">
|
||||
<mxGeometry x="275" y="1630" width="300" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
|
||||
<!-- Edges Step 1 -->
|
||||
<mxCell id="ep1" edge="1" source="p1" target="p2" parent="1"><mxGeometry relative="1" as="geometry" /></mxCell>
|
||||
<mxCell id="ep2" edge="1" source="p2" target="p3" parent="1"><mxGeometry relative="1" as="geometry" /></mxCell>
|
||||
<mxCell id="ep3" edge="1" source="p3" target="p4" parent="1"><mxGeometry relative="1" as="geometry" /></mxCell>
|
||||
<mxCell id="ep4" edge="1" source="p4" target="p5" parent="1"><mxGeometry relative="1" as="geometry" /></mxCell>
|
||||
<mxCell id="ep5" edge="1" source="p4" target="p6" parent="1">
|
||||
<mxGeometry relative="1" as="geometry"><Array as="points"><mxPoint x="625" y="415" /><mxPoint x="650" y="430" /></Array></mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ep6" value="否" edge="1" source="p6" target="p9" parent="1">
|
||||
<mxGeometry relative="1" as="geometry"><Array as="points"><mxPoint x="900" y="430" /></Array></mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ep7" value="是" edge="1" source="p6" target="p7" parent="1"><mxGeometry relative="1" as="geometry" /></mxCell>
|
||||
<mxCell id="ep8" value="是（超限）" edge="1" source="p7" target="p10" parent="1">
|
||||
<mxGeometry relative="1" as="geometry"><Array as="points"><mxPoint x="900" y="525" /></Array></mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ep9" value="否（未超限）" edge="1" source="p7" target="p8" parent="1"><mxGeometry relative="1" as="geometry" /></mxCell>
|
||||
|
||||
<!-- Step 2 edges -->
|
||||
<mxCell id="ep10" edge="1" source="p5" target="p11" parent="1"><mxGeometry relative="1" as="geometry" /></mxCell>
|
||||
<mxCell id="ep11" edge="1" source="p11" target="p12" parent="1"><mxGeometry relative="1" as="geometry" /></mxCell>
|
||||
<mxCell id="ep12" edge="1" source="p12" target="p13" parent="1"><mxGeometry relative="1" as="geometry" /></mxCell>
|
||||
<mxCell id="ep13" value="否（无效/过期）" edge="1" source="p13" target="p14" parent="1">
|
||||
<mxGeometry relative="1" as="geometry"><Array as="points"><mxPoint x="620" y="965" /></Array></mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ep14" value="重新申请" edge="1" source="p14" target="p2" parent="1">
|
||||
<mxGeometry relative="1" as="geometry"><Array as="points"><mxPoint x="960" y="970" /><mxPoint x="960" y="230" /><mxPoint x="625" y="230" /></Array></mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ep15" value="是（有效）" edge="1" source="p13" target="p15" parent="1"><mxGeometry relative="1" as="geometry" /></mxCell>
|
||||
|
||||
<!-- Step 3 edges -->
|
||||
<mxCell id="ep16" edge="1" source="p15" target="p16" parent="1"><mxGeometry relative="1" as="geometry" /></mxCell>
|
||||
<mxCell id="ep17" edge="1" source="p16" target="p17" parent="1"><mxGeometry relative="1" as="geometry" /></mxCell>
|
||||
<mxCell id="ep18" value="不通过" edge="1" source="p17" target="p18" parent="1">
|
||||
<mxGeometry relative="1" as="geometry"><Array as="points"><mxPoint x="640" y="1305" /></Array></mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ep19" value="" edge="1" source="p18" target="p16" parent="1">
|
||||
<mxGeometry relative="1" as="geometry"><Array as="points"><mxPoint x="760" y="1205" /></Array></mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ep20" value="通过" edge="1" source="p17" target="p19" parent="1"><mxGeometry relative="1" as="geometry" /></mxCell>
|
||||
<mxCell id="ep21" value="不通过" edge="1" source="p19" target="p20" parent="1">
|
||||
<mxGeometry relative="1" as="geometry"><Array as="points"><mxPoint x="640" y="1420" /></Array></mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ep22" value="" edge="1" source="p20" target="p16" parent="1">
|
||||
<mxGeometry relative="1" as="geometry"><Array as="points"><mxPoint x="760" y="1205" /></Array></mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="ep23" value="通过" edge="1" source="p19" target="p21" parent="1"><mxGeometry relative="1" as="geometry" /></mxCell>
|
||||
<mxCell id="ep24" edge="1" source="p21" target="p22" parent="1"><mxGeometry relative="1" as="geometry" /></mxCell>
|
||||
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
</diagram>
|
||||
|
||||
</mxfile>
|
||||
303
Project/fonrey/TECH_STACK/登录管理技术方案.md
Normal file
303
Project/fonrey/TECH_STACK/登录管理技术方案.md
Normal file
@@ -0,0 +1,303 @@
|
||||
# Fonrey 登录管理系统技术方案
|
||||
|
||||
**版本**: 1.0 | **项目**: Fonrey 房产经纪管理系统 | **技术栈**: Django 4.x + HTMX + Alpine.js + PostgreSQL + Redis + Celery
|
||||
**关联 PRD**: `Project/fonrey/PRD/登录管理/用户登录管理模块PRD.md` (v1.3)
|
||||
|
||||
> **For AI assistants**: Read this entire file before writing any code.
|
||||
> All decisions here are final. Do not suggest alternatives unless asked.
|
||||
|
||||
---
|
||||
|
||||
## 一、模块定位与架构边界
|
||||
|
||||
登录管理模块（`accounts` App）负责多租户环境下的身份识别、认证、账号安全及凭据找回。其架构边界如下：
|
||||
|
||||
| 层级 | 位置 | 说明 |
|
||||
|------|------|------|
|
||||
| Tenant ID 验证 | `shared_apps`（公共 Schema） | 属于平台基础服务，在 `public` schema 下运行，无需租户切换 |
|
||||
| 账号认证、找回密码等 | 租户 Schema（Tenant Schema） | 通过请求域名 `{tenant_slug}.fonrey.com` 自动切换，`django-tenants` 中间件处理 |
|
||||
| Electron 客户端 | 前端 | 负责 Tenant ID 本地缓存、Session Token 管理、页面加载 |
|
||||
|
||||
---
|
||||
|
||||
## 二、依赖与技术选型
|
||||
|
||||
| 依赖项 | 版本/方案 | 用途 | 说明 |
|
||||
|--------|-----------|------|------|
|
||||
| `django.contrib.auth` | Django 内置 | 用户认证基础框架 | 扩展 `AbstractBaseUser`，**不直接使用** `User` 模型；username 唯一性约束在租户 Schema 维度生效，而非全局 |
|
||||
| `django-tenants` | 已有 | 多租户隔离 | `UserAccount` 在租户 Schema；Tenant 验证接口在 `shared_apps` |
|
||||
| `PostgreSQL` | 已有 | 数据持久化 | Schema 级别隔离租户数据 |
|
||||
| `Redis` | 必须 | 多用途缓存 | 滑块验证 Token（TTL 3min）、登录失败计数（TTL 30min）、密码重置 Token 缓存 |
|
||||
| `Celery` | 必须 | 异步任务队列 | 邮件发送异步处理，防止登录/找回接口超时 |
|
||||
| `Pillow` | 必须（若自研验证码） | 图片处理 | 生成拼图背景图（抠出缺口）+ 拼图碎片，输出 Base64 |
|
||||
| `django-ratelimit` 或自定义中间件 | 必须 | 接口限流 | Tenant 验证、登录、找回密码接口均需限流 |
|
||||
| `electron-store` 或 AES 加密文件 | Electron 侧 | 本地持久化 | 加密存储 Tenant ID，不存明文；路径为 `app.getPath('userData')` |
|
||||
| `secrets` (Python 标准库) | Python 内置 | Token 生成 | 使用 `secrets.token_urlsafe(32)` 生成密码重置 Token |
|
||||
|
||||
### 滑块验证码方案选型（待确认，见开放问题）
|
||||
|
||||
| 方案 | 优点 | 缺点 |
|
||||
|------|------|------|
|
||||
| 自研（Pillow + 前端拖拽组件） | 完全可控，无外部依赖，数据合规性好 | 需维护图库，需自己实现轨迹检测算法 |
|
||||
| 第三方服务（极验 GeeTest / 网易易盾） | 开箱即用，安全性更高 | 引入外部依赖，有数据合规风险，需评估 |
|
||||
|
||||
**当前方案**：暂按自研设计，后端负责人需在开发启动前确认最终选型。
|
||||
|
||||
---
|
||||
|
||||
## 三、目录结构
|
||||
|
||||
```
|
||||
fonrey/apps/
|
||||
└── accounts/ # 账号认证管理（租户级 App）
|
||||
├── models.py # UserAccount, LoginAttempt, PasswordResetToken
|
||||
├── views.py # 登录/登出/找回账号/找回密码视图
|
||||
├── urls.py
|
||||
├── serializers.py # API 序列化（JSON 接口）
|
||||
└── services/
|
||||
├── auth.py # 认证逻辑（验证码校验、账号锁定判断）
|
||||
├── recovery.py # 找回密码/用户名逻辑（含邮件发送 Celery 任务）
|
||||
└── tenant.py # Tenant 验证逻辑（属于 shared_apps，公共 Schema）
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 四、数据模型
|
||||
|
||||
### 4.1 `UserAccount`（核心账号表，位于租户 Schema）
|
||||
|
||||
```python
|
||||
class UserAccount(AbstractBaseUser):
|
||||
id = BigAutoField(primary_key=True)
|
||||
username = CharField(max_length=30) # 同租户内唯一；普通员工为手机号；Tenant Admin 为自定义字符串
|
||||
email = EmailField(null=True, blank=True) # 同租户唯一，为空则无法自助找回密码
|
||||
phone = CharField(max_length=11, null=True) # 加密存储（core.encryption）；普通员工必填
|
||||
staff = OneToOneField('org.Staff', null=True, on_delete=SET_NULL) # 实名绑定；普通员工必须
|
||||
is_tenant_admin = BooleanField(default=False)
|
||||
status = CharField(max_length=10) # active / disabled / locked
|
||||
is_initial_password = BooleanField(default=True) # True → 登录后强制跳转修改密码
|
||||
last_login = DateTimeField(null=True)
|
||||
created_at = DateTimeField(auto_now_add=True)
|
||||
created_by = ForeignKey('self', null=True, on_delete=SET_NULL)
|
||||
|
||||
USERNAME_FIELD = 'username'
|
||||
|
||||
class Meta:
|
||||
unique_together = [('username',)] # Schema 内唯一，跨租户不冲突
|
||||
```
|
||||
|
||||
**关键约束**：
|
||||
- `username` 唯一性约束仅在当前租户 Schema 内生效（`django-tenants` 隔离机制），不同租户可以有相同 username
|
||||
- 密码存储使用 Django 默认 `PBKDF2+SHA256`（`make_password`），**后端不得明文存储或传输**
|
||||
- `phone` 字段使用 `core.encryption` 加密存储
|
||||
|
||||
### 4.2 `LoginAttempt`（登录审计，位于租户 Schema）
|
||||
|
||||
```python
|
||||
class LoginAttempt(Model):
|
||||
username = CharField(max_length=30)
|
||||
ip_address = GenericIPAddressField()
|
||||
success = BooleanField()
|
||||
failure_reason = CharField(max_length=30, null=True)
|
||||
# 可选值：wrong_password / wrong_captcha / account_locked / account_disabled
|
||||
attempted_at = DateTimeField(auto_now_add=True)
|
||||
```
|
||||
|
||||
**保留策略**：合规审计数据，**最少保留 90 天**，不得提前清理。
|
||||
|
||||
### 4.3 `PasswordResetToken`（密码重置令牌，位于租户 Schema）
|
||||
|
||||
```python
|
||||
class PasswordResetToken(Model):
|
||||
user = ForeignKey(UserAccount, on_delete=CASCADE)
|
||||
token = CharField(max_length=64) # secrets.token_urlsafe(32) 生成
|
||||
expires_at = DateTimeField() # created_at + 30 分钟
|
||||
is_used = BooleanField(default=False)
|
||||
created_at = DateTimeField(auto_now_add=True)
|
||||
```
|
||||
|
||||
**安全约束**：
|
||||
- Token 单次有效（使用后立即设 `is_used=True`）
|
||||
- 有效期 30 分钟，过期后拒绝使用
|
||||
- 同一账号 1 小时内最多生成 3 个有效 Token（服务端计数）
|
||||
|
||||
---
|
||||
|
||||
## 五、Redis Key 规范
|
||||
|
||||
| 用途 | Key 格式 | TTL | 说明 |
|
||||
|------|----------|-----|------|
|
||||
| 滑块验证会话 Token | `captcha_token:{uuid}` | 3 分钟 | 前端拖动完成后服务端生成一次性通过凭证 |
|
||||
| 登录失败计数 | `login_fail:{tenant_id}:{username}` | 30 分钟 | 计数 ≥ 5 时锁定账号；TTL 30 分钟自动解锁 |
|
||||
| 找回邮件发送频率 | `recover_email:{email}` | 1 小时 | 记录已发送次数，上限 3 次/小时 |
|
||||
| Tenant ID 限流 | `tenant_verify_ip:{ip}` | 1 分钟 | 计数 ≥ 10 时拒绝请求 |
|
||||
|
||||
---
|
||||
|
||||
## 六、接口清单
|
||||
|
||||
| 接口 | 方法 | Schema 位置 | 是否需要鉴权 | 限流规则 | 说明 |
|
||||
|------|------|------------|------------|---------|------|
|
||||
| `/api/auth/tenant/verify/` | POST | Public（shared） | 否 | 每 IP 每分钟 ≤ 10 次 | Tenant ID 验证 |
|
||||
| `/api/auth/captcha/` | GET | Tenant | 否 | — | 获取滑块拼图验证码（背景图 Base64 + 碎片图 Base64 + 验证 Token） |
|
||||
| `/api/auth/captcha/verify/` | POST | Tenant | 否 | — | 提交滑动轨迹 + 位置，返回一次性通过凭证 |
|
||||
| `/api/auth/login/` | POST | Tenant | 否 | 每 IP 每分钟 ≤ 20 次 | 账号密码登录 |
|
||||
| `/api/auth/logout/` | POST | Tenant | 是 | — | 登出，使服务端 Session 失效 |
|
||||
| `/api/auth/recover/username/` | POST | Tenant | 否 | 每邮箱每小时 ≤ 3 次 | 发起找回用户名（发送邮件） |
|
||||
| `/api/auth/recover/password/request/` | POST | Tenant | 否 | 每账号每小时 ≤ 3 次 | 发起找回密码（发送重置链接邮件） |
|
||||
| `/api/auth/recover/password/reset/` | POST | Tenant | 否（Token 鉴权） | — | 提交新密码，使用 PasswordResetToken 校验 |
|
||||
| `/api/auth/login/phone/` | POST | Tenant | 否 | — | **预留**，v2 实现，手机验证码登录 |
|
||||
| `/api/auth/wechat/qrcode/` | GET | Tenant | 否 | — | **预留**，v2 实现，获取微信二维码 |
|
||||
| `/api/auth/wechat/callback/` | POST | Tenant | 否 | — | **预留**，v2 实现，微信扫码回调 |
|
||||
|
||||
### Tenant 验证接口 Request/Response 规范
|
||||
|
||||
```
|
||||
POST /api/auth/tenant/verify/
|
||||
|
||||
Request Body:
|
||||
{
|
||||
"tenant_id": "202500010001" // 固定 12 位纯数字
|
||||
}
|
||||
|
||||
Response 200 (成功):
|
||||
{
|
||||
"valid": true,
|
||||
"tenant_name": "XX房产经纪有限公司",
|
||||
"tenant_logo_url": "https://cdn.fonrey.com/tenants/xxx/logo.png",
|
||||
"login_url": "https://xxx.fonrey.com/auth/login/"
|
||||
}
|
||||
|
||||
Response 200 (失败):
|
||||
{
|
||||
"valid": false,
|
||||
"error_code": "TENANT_NOT_FOUND",
|
||||
"message": "识别码无效"
|
||||
}
|
||||
```
|
||||
|
||||
> **注意**：失败响应统一返回 HTTP 200，不区分"未找到"与"已禁用"，防止枚举攻击。
|
||||
|
||||
### 登录接口核心逻辑
|
||||
|
||||
```
|
||||
POST /api/auth/login/
|
||||
|
||||
Request Body:
|
||||
{
|
||||
"username": "string",
|
||||
"password": "string",
|
||||
"captcha_token": "string", // 滑块验证通过后的一次性凭证
|
||||
"captcha_pass_token": "string"
|
||||
}
|
||||
|
||||
Response 200 (成功):
|
||||
{
|
||||
"token": "...",
|
||||
"user": {
|
||||
"id": 1,
|
||||
"username": "...",
|
||||
"display_name": "...",
|
||||
"is_initial_password": false
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 七、安全机制设计
|
||||
|
||||
### 7.1 滑块拼图验证码
|
||||
|
||||
- **图片生成**：`Pillow` 从预置图库随机抽取背景图，服务端随机生成缺口位置，抠出缺口并生成拼图碎片，两者分别以 Base64 返回前端
|
||||
- **轨迹校验**：前端记录滑动过程的坐标序列 + 时间戳，提交至 `/api/auth/captcha/verify/`；服务端综合校验：
|
||||
- **位置偏差**：碎片最终位置与缺口中心偏差 ≤ ±5px
|
||||
- **轨迹特征**：存在加速→减速的非线性运动曲线；拒绝匀速/程序化轨迹
|
||||
- **独立性**：验证码失败**不计入**账号密码错误次数，两者独立计数
|
||||
- **有效期**：通过凭证（`captcha_pass_token`）TTL 3 分钟，单次有效
|
||||
|
||||
### 7.2 账号锁定机制
|
||||
|
||||
- 同一账号（`login_fail:{tenant_id}:{username}`）连续密码错误 ≥ 5 次：
|
||||
- 账号状态置为 `locked`，持续 30 分钟
|
||||
- Redis TTL 30 分钟到期后自动恢复，同时 `status` 更新为 `active`
|
||||
- Tenant Admin 可在管理界面手动解锁（提前恢复）
|
||||
|
||||
### 7.3 密码安全
|
||||
|
||||
| 规则 | 说明 |
|
||||
|------|------|
|
||||
| 存储哈希 | Django `PBKDF2+SHA256`（`make_password`） |
|
||||
| 传输安全 | 强制 HTTPS，前端**不加密**密码（HTTPS 层保证） |
|
||||
| 复杂度 | 长度 8~32 位，必须包含字母（区分大小写）+ 数字；建议特殊符号（非强制） |
|
||||
| 历史密码 | 不得与最近 3 次历史密码相同（含系统固定初始密码 `Fonrey@2025`） |
|
||||
| Session 有效期 | 默认 8 小时；可由 Tenant Admin 在「系统设置」中调整 |
|
||||
|
||||
### 7.4 密码重置流程安全要点
|
||||
|
||||
- Token 由 `secrets.token_urlsafe(32)` 生成，64 字符，全局唯一
|
||||
- 单次有效：使用后立即标记 `is_used=True`
|
||||
- 有效期 30 分钟（`expires_at = created_at + timedelta(minutes=30)`）
|
||||
- 重置成功后：清除该账号所有有效 Session（强制重新登录）
|
||||
- 重置成功后：`is_initial_password = False`
|
||||
|
||||
---
|
||||
|
||||
## 八、Electron 客户端约定
|
||||
|
||||
| 约定项 | 规格 |
|
||||
|--------|------|
|
||||
| Tenant ID 存储 | `electron-store` 或 `app.getPath('userData')` + AES 加密文件，**不存明文** |
|
||||
| Session Token 存储 | 内存（`global` 变量）+ Chromium `session` Cookie，**不写入磁盘明文文件** |
|
||||
| 登录页加载方式 | 主进程根据 Tenant ID 构建 `https://{tenant_slug}.fonrey.com/auth/login/`，通过 `BrowserWindow.loadURL()` 加载 |
|
||||
| 多标签页 | 同一 `BrowserWindow` 内所有页面共享同一 Session Cookie |
|
||||
| 客户端登出 | 调用 `POST /api/auth/logout/` 使服务端 Session 失效 + 清除 Chromium Session Cookie |
|
||||
| 窗口关闭 | Session 保留（不自动登出），下次打开若 Session 未过期则直接进入系统 |
|
||||
| 强制更新 | 客户端版本低于服务端 `min_required_version` 时，阻断登录流程，展示更新提示 |
|
||||
|
||||
---
|
||||
|
||||
## 九、多租户隔离要点
|
||||
|
||||
- `UserAccount`、`LoginAttempt`、`PasswordResetToken` 均位于**租户 Schema 内**，数据完全隔离
|
||||
- `username` 唯一性约束在 Schema 维度生效，不同租户可以存在相同 username
|
||||
- Tenant 验证接口（`/api/auth/tenant/verify/`）位于 **Public Schema**（`shared_apps`），查询 `TenantModel`
|
||||
- 登录等接口通过请求域名（`{tenant_slug}.fonrey.com`）自动切换 Schema，由 `django-tenants` 中间件处理，**无需手动切换**
|
||||
|
||||
---
|
||||
|
||||
## 十、已知风险与缓解措施
|
||||
|
||||
| 风险 | 可能性 | 影响 | 缓解措施 |
|
||||
|------|--------|------|---------|
|
||||
| 滑块验证被机器模拟轨迹绕过 | 低 | 高 | 服务端同时校验位置偏差 + 轨迹曲线特征，拒绝匀速/程序化轨迹；后续可引入设备指纹 |
|
||||
| Tenant ID 枚举攻击 | 低 | 中 | 限流（每 IP 每分钟 ≤ 10 次）；响应不区分"未找到"与"已禁用" |
|
||||
| 密码重置 Token 泄露 | 低 | 高 | 单次有效 + 30 分钟过期 + HTTPS 传输 |
|
||||
| 邮件发送失败 | 中 | 中 | 异步任务失败写入告警日志；管理员可通过后台查看 Token 手动告知用户 |
|
||||
| 多端并发登录 | 高（正常场景） | 低 | 本期允许；v2 可在 Token 引入版本号实现踢出策略 |
|
||||
|
||||
---
|
||||
|
||||
## 十一、开放问题（开发启动前必须确认）
|
||||
|
||||
| 问题 | 负责人 | 截止 |
|
||||
|------|--------|------|
|
||||
| 邮件服务商选型：SendGrid / 阿里云邮件推送 / SMTP 自建？ | 后端负责人 + 运维 | 开发启动前 |
|
||||
| 滑块验证码方案：自研（Pillow）还是第三方（极验 / 网易易盾）？ | 后端负责人 + 安全 | 开发启动前 |
|
||||
| Session 有效期默认值 8 小时，是否允许 Tenant Admin 自行配置？ | 产品经理 | 开发启动前 |
|
||||
| 账号锁定后是否自动发邮件通知用户和/或管理员？ | 产品经理 | 开发启动前 |
|
||||
| 历史密码校验范围：最近 3 次是否足够？是否增加"不得与用户名相同"规则？ | 产品经理 | 开发启动前 |
|
||||
|
||||
---
|
||||
|
||||
## 十二、明确禁止
|
||||
|
||||
- ❌ 不得使用 Django 原生 `User` 模型，必须扩展 `AbstractBaseUser`
|
||||
- ❌ 不得在全局 Schema 创建 `UserAccount` 表（必须在租户 Schema 内）
|
||||
- ❌ 不得明文存储或传输密码
|
||||
- ❌ 不得在 `LoginAttempt` 记录中存储密码明文（含错误密码）
|
||||
- ❌ 不得在前端做密码哈希（HTTPS 层保证传输安全）
|
||||
- ❌ 不得将 Session Token 写入 Electron 磁盘明文文件
|
||||
- ❌ 不得在找回账号/密码响应中区分"邮箱存在"与"邮箱不存在"（防止枚举）
|
||||
- ❌ `PasswordResetToken` 不得重复使用（`is_used=True` 后立即失效）
|
||||
- ❌ 登录失败响应不得区分"用户名错误"与"密码错误"
|
||||
248
ishenwei/blogwatcher/2026-04-25.md
Normal file
248
ishenwei/blogwatcher/2026-04-25.md
Normal file
@@ -0,0 +1,248 @@
|
||||
|
||||
## 📦 新增 69 篇 (06:01:49)
|
||||
|
||||
### 【Tech With Tim - YouTube】
|
||||
|
||||
- [Local Models Got a HUGE Upgrade - Full Guide (Ollama/OpenClaw)](https://www.youtube.com/watch?v=73UEJxAWzb0)
|
||||
Get a chance to win a FREE Mac Mini with ClawComp: https://clawcomp.net/PromptCast: https://www.youtube.com/@PromptCastOfficialLocal models just got a...
|
||||
|
||||
### 【Brayden Chen - YouTube】
|
||||
|
||||
- [從借錢發薪水, 一個月只賣出一包, 到免費登上超級杯, 連NASA太空人都在喝他的咖啡, 會計師辭職賣咖啡, 無意中調出全世界最強咖啡｜白手起家創業故事｜Brayden布...](https://www.youtube.com/watch?v=YFHvxXOJ2Bs)
|
||||
從瀕臨破產、住在媽媽車庫，到打造「全世界最強咖啡」，Mike Brown 的創業故事是一套完整的 0到1流量打法教科書。這支影片帶你拆解他如何用「零預算行銷」、「媒體槓桿」、「SEO + 社群策略」，一步步拿下第一個客戶，如果你正在創業、沒有資金、不知道如何獲取流量，這支影片會給你一套可以直接複製的...
|
||||
|
||||
### 【TEDx Talks - YouTube】
|
||||
|
||||
- [Why are so many adult children moving back home? | Julie Lythcott-Haims | TEDxSonomaCounty](https://www.youtube.com/watch?v=axHcRxnnv2Q)
|
||||
Julie Lythcott-Haims offers a compassionate look at what happens when adult children move back home. What she once saw as a setback became an unexpect...
|
||||
|
||||
- [Delete your budgeting app | Joseph Okaly | TEDxEustis](https://www.youtube.com/watch?v=BPpBx-VGy1A)
|
||||
In this talk, Joseph Okaly challenges one of the most common assumptions about personal finance: that budgeting is the key to building wealth. Drawing...
|
||||
|
||||
- [What I learned about courage after losing my identity | Jordan Babineaux | TEDxEustis](https://www.youtube.com/watch?v=mdeqha9cA00)
|
||||
What I Learned About Change After Losing the Only Identity I KnewWhat do you do next when your career is disrupted, your business fails, or your ident...
|
||||
|
||||
- [What is Mentorship? Mentorship is Messy | Artis Stevens | TEDxWakeForestU](https://www.youtube.com/watch?v=gRqAuNadPSU)
|
||||
Across America, everyone -- especially young people -- are seeking connection in a world that feels increasingly divided. In this urgent moment, Artis...
|
||||
|
||||
- [The Unknown Originator of The Atom | Kabir Chadha | TEDxQESB Youth](https://www.youtube.com/watch?v=-OZcYpoxXYw)
|
||||
What if one of the first ideas about atoms came from someone simply breaking a grain of rice? This talk explores the story of Kaṇāda, whose ancient in...
|
||||
|
||||
- [The transformative power of intentional love | Clayton Kirkland | TEDxEustis](https://www.youtube.com/watch?v=28WMOpt_9CE)
|
||||
In this heartfelt TEDx Talk, Clayton W. Kirkland explores the transformative power of intentional love and how conscious choices can break cycles of a...
|
||||
|
||||
- [How to Make Third Spaces Reappear | Asha Bunting | TEDxLIU](https://www.youtube.com/watch?v=rpP8wE9RXtI)
|
||||
Nowadays people are spending more time at home. At the same time, third spaces are seemingly disappearing... Is this really true? Asha is a senior at ...
|
||||
|
||||
- [Not Saviours but Stakeholders: A New Model for Aid | Keshav Aggarwal | TEDxQESB Youth](https://www.youtube.com/watch?v=Cp4W-vJIRTg)
|
||||
The future of aid is not charity, it’s partnership - not saviours but stakeholders.This talk dives into a central paradox in development economics: th...
|
||||
|
||||
- [The Reality of Moving Schools | Yirumy Kim | TEDxBBIS Youth](https://www.youtube.com/watch?v=KZkj3hUbaNQ)
|
||||
What is it really like to start over in a new school? This talk explores the loneliness, pressure, and identity shifts that come with being the “new s...
|
||||
|
||||
- [My Problem with Faith | Szonja Rakosi | TEDxBBIS Youth](https://www.youtube.com/watch?v=gdJ-nR5MAKY)
|
||||
What happens when your faith begins to feel uncertain or distant? This talk explores the struggle of questioning beliefs, the fear that comes with dou...
|
||||
|
||||
### 【灵姐说AI | Ling Talk AI - YouTube】
|
||||
|
||||
- [別再無腦選最強模型了，AI Agent 真正的省錢玩法來了 ｜ Claude Advisor Strategy](https://www.youtube.com/watch?v=RfboM6j6wpI)
|
||||
AI Agent 时代，真的还要每个任务都无脑选择最强模型吗？Claude 最近发布的 Advisor Strategy，给了一个很有启发性的答案：让 Sonnet / Haiku 这类执行模型负责跑流程，把 Opus 这类强模型放在关键节点做顾问。换句话说，不是每件事都让最贵、最强的模型亲自干活，...
|
||||
|
||||
### 【Coursera - YouTube】
|
||||
|
||||
- [The Key Ingredients in Cosmetics Explained](https://www.youtube.com/watch?v=KCwc9rbgdcg)
|
||||
Every cosmetic product is powered by carefully selected ingredients. This lecture explores the essential building blocks of cosmetics—from surfactants...
|
||||
|
||||
- [Changing Careers at 50: A Practical Guide](https://www.youtube.com/watch?v=fWQfg3LQkqs)
|
||||
A career change in your 50s can be the start of something meaningful and rewarding. This video explores how to transition into a new path by building ...
|
||||
|
||||
### 【無遠弗屆教學教室 - YouTube】
|
||||
|
||||
- [Manus My Computer 實測｜5 個最實用的電腦工作自動化功能](https://www.youtube.com/watch?v=2FBb8zb-sAU)
|
||||
立即註冊 Manus點擊以下註冊 Manus 會員，還可以免費增加 1000 點點數：https://manus.im/redeem?c=mwiyytb你是不是也常常遇到這些情況？找不到電腦裡的檔案、資料太多懶得整理、硬碟容量快爆了、出門才發現重要文件沒帶，甚至連幾份 PDF 報告都懶得一份一份慢慢...
|
||||
|
||||
### 【零度解说 - YouTube】
|
||||
|
||||
- [终于来了！DeepSeek-V4 正式发布！免费开源，百万上下文，Agent能力直逼Claude！| 零度解说](https://www.youtube.com/watch?v=FIBfRo-rHBo)
|
||||
【更多资源】▶https://bittly.cc/lingdu【零度博客】▶https://www.freedidi.com【加入会员】▶https://www.youtube.com/channel/UCvijahEyGtvMpmMHBu4FS2w/join【高级会员】▶https://bittl...
|
||||
|
||||
### 【Bloomberg Originals - YouTube】
|
||||
|
||||
- [Why Anthropic’s Mythos Is Sparking Alarm](https://www.youtube.com/watch?v=JmFKaqJg5X4)
|
||||
Mythos has sparked fear as artificial intelligence looks to be advancing faster than it can be safely deployed. But the furor over the AI model could ...
|
||||
|
||||
### 【Reuters - YouTube】
|
||||
|
||||
- [Business Lookahead: Lots of talk, lots of tech](https://www.youtube.com/watch?v=12pySnSVWPU)
|
||||
From uncertainty over Iran to a mega earnings week, these are the stories to watch in business and finance in the coming week. #business #powell #trum...
|
||||
|
||||
- [Market Talk: 'Quieter' Fed under Warsh could be a 'double-edged sword'](https://www.youtube.com/watch?v=p4eXvLXSO_4)
|
||||
Fed Chair nominee Kevin Warsh's desire for less public discussion on interest rates could reduce blunders but risks misleading investors, Robert Conzo...
|
||||
|
||||
- [Veteran foreigners in Spain keep fit with walking football](https://www.youtube.com/watch?v=FjDS7exPkzE)
|
||||
Veteran foreigners living in Spain’s Costa del Sol laced up their boots for a friendly game of walking football, welcoming a visiting team from the Un...
|
||||
|
||||
- [Pete Hegseth says Iran blockade 'going global'](https://www.youtube.com/watch?v=EQONgkAHCKI)
|
||||
Defense Secretary Pete Hegseth said that the US naval blockade on Iran was expanding globally, adding that Tehran had a chance to make 'a good deal.'#...
|
||||
|
||||
- [Burundi begins returning Congolese refugees after M23 takeover](https://www.youtube.com/watch?v=_sqxZUTYOIw)
|
||||
Burundi has started returning Congolese refugees to eastern Democratic Republic of Congo with the first organized convoy since M23 fighters seized key...
|
||||
|
||||
- [P&G warns of $1 billion profit hit from higher oil prices](https://www.youtube.com/watch?v=ib3MADmYoqw)
|
||||
US consumer goods giant Procter & Gamble warned of a roughly $1 billion post-tax hit to its fiscal 2027 profit from surging oil prices, joining a host...
|
||||
|
||||
- [Purdue opioid victims' years-long fight for justice lost to paperwork](https://www.youtube.com/watch?v=pgBqbI1pgkY)
|
||||
New York's Michael Galipeau is among tens of thousands of people who may receive nothing from OxyContin maker Purdue Pharma's agreement to pay $865 mi...
|
||||
|
||||
- [US envoys head to Pakistan for Iran war talks](https://www.youtube.com/watch?v=4UgI_4c6lxc)
|
||||
The White House said that special envoy Steve Witkoff and Jared Kushner would travel to Islamabad for Pakistan-mediated talks with Iran, with Vice Pre...
|
||||
|
||||
- [Justice Department to close investigation into Fed Chair Powell](https://www.youtube.com/watch?v=zr2EZnrzYAs)
|
||||
The Justice Department is closing its investigation into Federal Reserve Chair Jerome Powell, US Attorney Jeanine Pirro said, removing an obstacle to ...
|
||||
|
||||
- [Russian attack on Ukraine's Odesa kills married couple, officials say](https://www.youtube.com/watch?v=ruMHYJcnAAk)
|
||||
A Russian drone attack on Odesa killed a married couple and injured more than a dozen people, according to Ukrainian officials.#News #Reuters #Newsfee...
|
||||
|
||||
### 【BBC News 中文 - YouTube】
|
||||
|
||||
- [「他們說父親已去世」：肯亞英軍基地子女尋找生父－ BBC News 中文](https://www.youtube.com/watch?v=6Q5cAZDBW1o)
|
||||
自1950年代以來，在肯亞一處英軍基地附近，已有近100宗記錄在案的案例，涉及英國士兵與當地女性所生的兒女。這些孩子多數在不知父親身分的情況下長大，有些人面臨貧困或遭社區排斥。他們開始透過一名英國律師的協助尋找答案。該律師首次將商業DNA資料庫的證據引入家庭法院程序。BBC《World of Sec...
|
||||
|
||||
### 【理想生活实验室】
|
||||
|
||||
- [今日消费资讯：黛米·摩尔出任兰蔻全球品牌代言人、lululemon 任命 Heidi O'Neill 成为 CEO](http://www.toodaylab.com/84009)
|
||||
星巴克《穿普拉达的女王 2》电影合作系列上市4 月 23 日，星巴克和《穿普拉达的女王 2》电影合作系列正式发售，合作以“双料狠角”为主题，星巴克带来了全新的鸳鸯系列，同时也推出了限定合作款周边产品。其中鸳鸯系列包括了抹茶鸳鸯和红茶鸳鸯，前者采用龙井 43 鲜叶制成的超千目一级抹茶，同时搭配星巴克高...
|
||||
|
||||
### 【阿榮福利味 - 免費軟體下載】
|
||||
|
||||
- [[正版購買] Kutools for Word 23.00 繁體中文版 - Word 功能增強外掛 超過 100 種功能](https://www.azofreeware.com/2017/11/kutools-for-word.html)
|
||||
Word 功能增強外掛 - Kutools for Word，微軟 Office Word 的實用外掛，超過 100 種功能增強，例如：匯出圖片、匯出表格為圖片、插入註解、超連結管理、表格轉換為文字、插入書籤、重新命名文件、清除分隔符號、清除縮排、清除空白行、清除多餘空格。（阿榮福利味） 購買連結（...
|
||||
|
||||
- [Tenorshare iCareFone Transfer 5.6.12 中文版 - WhatsApp 手機資料轉移 安卓轉蘋果 蘋果與安卓互轉](https://www.azofreeware.com/2020/10/icarefone-for-whatsapp-transfer.html)
|
||||
WhatsApp 換機手機資料轉移 - Tenorshare iCareFone Transfer，幫你在換機時輕鬆將 WhatsApp 由 Android 轉 iOS，安卓轉蘋果或蘋果轉安卓都可以雙向互轉，支援最新版 iOS 作業系統及 iPhone 手機，不需要 iCloud 或整機備份，完整轉...
|
||||
|
||||
- [[正版購買] CCleaner 7.07.1313 中文版 - 硬碟清理軟體兼驅動程式更新軟體](https://www.azofreeware.com/2006/10/ccleaner-134407.html)
|
||||
CCleaner 從問世到現在，使用數年卻不曾見它出過差錯，由此可見程式設計者的態度與功力，你可以放心使用他來清理一些硬碟中的暫存檔，讓電腦多出更多的可用空間，也可以掃瞄登錄檔的問題，並且讓它修復你的登錄檔，但為了確保萬一，修復前還是順手備份一下吧！付費版功能：驅動程式更新工具、軟體更新工具、完整的...
|
||||
|
||||
- [Vivaldi 韋瓦第瀏覽器 7.9.3970.59 免安裝中文版 - Opera 創辦人所出品的類 Chrome 瀏覽器](https://www.azofreeware.com/2016/03/vivaldiportable.html)
|
||||
Opera 創辦人所出品的類 Chrome 瀏覽器 - Vivaldi (韋瓦第瀏覽器)，由 Opera 創辦人兼前執行長譚詠文的新公司（Vivaldi Technologies）所主導開發的新型瀏覽器，以可自訂的個性瀏覽器為主要訴求，主要特色有：頁籤列可以自由設定在上下左右的位置，快捷指令功能（F...
|
||||
|
||||
- [Floorp Browser 12.12.2 免安裝中文版 - 注重隱私的類火狐瀏覽器](https://www.azofreeware.com/2026/01/floorp-browser.html)
|
||||
注重隱私的類火狐瀏覽器 - Floorp Browser，基於「Firefox」核心，由日本團隊開發的瀏覽器，強調隱私與高度自訂功能，內建追蹤攔截器，可以保護使用者免受網站的惡意追蹤，還提供指紋追蹤防護，讓你的上網行為更安全。（阿榮福利味） 下載連結→ https://www.azofreeware...
|
||||
|
||||
### 【Engadget is a web magazine with obsessive daily coverage of everything new in gadgets and consumer electronics】
|
||||
|
||||
- [XChat, the standalone app for messaging on X, is available on iOS now](https://www.engadget.com/apps/xchat-the-standalone-app-for-messaging-on-x-is-available-on-ios-now-214826886.html?src=rss)
|
||||
XChat, the standalone app for accessing X's messaging feature, is available to download now for iOS. X first suggested it would be stripping direct me...
|
||||
|
||||
- [Maine governor vetoes bill temporarily banning large data centers in the state](https://www.engadget.com/ai/maine-governor-vetoes-bill-temporarily-banning-large-data-centers-in-the-state-210407936.html?src=rss)
|
||||
The governor of Maine, Janet Mills, has vetoed a bill that halts the construction of large data centers in the state until the fall of 2027. While the...
|
||||
|
||||
- [A Battlefield movie adaptation is on the way, possibly starring Michael B. Jordan](https://www.engadget.com/entertainment/a-battlefield-movie-adaptation-is-on-the-way-possibly-starring-michael-b-jordan-201906079.html?src=rss)
|
||||
Have you ever noticed how Walgreens and CVS locations often end up across the street from each other? Well, Call of Duty and Battlefield have a simila...
|
||||
|
||||
- [The DOJ is backing xAI in its lawsuit against Colorado](https://www.engadget.com/ai/the-doj-is-backing-xai-in-its-lawsuit-against-colorado-200500890.html?src=rss)
|
||||
The Department of Justice has announced that it's intervening on the behalf of xAI in the company's recent lawsuit against the state of Colorado. xAI ...
|
||||
|
||||
- [What you need to know as Elon Musk's lawsuit against Sam Altman begins](https://www.engadget.com/ai/what-you-need-to-know-as-elon-musks-lawsuit-against-sam-altman-begins-191500726.html?src=rss)
|
||||
In a few short days, jury selection will begin in the long-awaited Musk v. Altman case. At the end of that process, an Oakland federal court will task...
|
||||
|
||||
- [Google plans to invest even more money into Anthropic](https://www.engadget.com/ai/google-plans-to-invest-even-more-money-into-anthropic-185000776.html?src=rss)
|
||||
Google plans to invest up to $40 billion into Anthropic in what could be viewed as a circular deal with the AI startup (and frequent competitor), Bloo...
|
||||
|
||||
- [Singapore police arrest alleged The Legend of Aang: The Last Airbender leaker](https://www.engadget.com/entertainment/streaming/singapore-police-arrest-alleged-the-legend-of-aang-the-last-airbender-leaker-183954803.html?src=rss)
|
||||
People aren't thrilled with Paramount these days. After all, corporate consolidation and the transformation of CBS News into state media tend to do th...
|
||||
|
||||
- [The MacBook Neo is a glimpse into John Ternus's Apple](https://www.engadget.com/computing/laptops/the-macbook-neo-is-a-glimpse-into-john-ternuss-apple-170000842.html?src=rss)
|
||||
John Ternus was unavoidable when Apple debuted the Macbook Neo. He kicked off an intimate media event for the Neo, introducing it as a transformative ...
|
||||
|
||||
- [Engadget Podcast: Tim Cook’s Apple era and what lies ahead for John Ternus](https://www.engadget.com/computing/engadget-podcast-tim-cooks-apple-era-and-what-lies-ahead-for-john-ternus-121853488.html?src=rss)
|
||||
The Apple rumors were true, once again. This week, the company announced that Tim Cook will be stepping down from his CEO role on September 1. Replaci...
|
||||
|
||||
- [DeepSeek promises its new AI model has 'world-class' reasoning](https://www.engadget.com/ai/deepseek-promises-its-new-ai-model-has-world-class-reasoning-115733512.html?src=rss)
|
||||
DeepSeek has released its latest AI models, the V4 Pro and Flash versions, a bit over a year after it went viral and became the top rated free app on ...
|
||||
|
||||
### 【异次元软件世界】
|
||||
|
||||
- [DeepSeek V4 Pro 来了！标配百万上下文，国产模型再次刷新开源 AI 天花板？](https://www.iplaysoft.com/deepseek-v4.html)
|
||||
今天一大消息就是开源 AI 大模型圈的“卷王” DeepSeek，憋了 15 个月后，终于把全新系列模型 DeepSeek-V4 正式公布出来了，而且照惯例，同步开源！ 一时间朋友圈、技术群各种消息满天飞。现在 DeepSeek 官网和 API 都直接能用 v4 了！包括众多第三方算力平台也陆续上线...
|
||||
|
||||
### 【小众软件】
|
||||
|
||||
- [Ubuntu 26.04 LTS 发布，支持到 2041 年，附升级方法](https://www.appinn.com/ubuntu-26-04-lts-release/)
|
||||
Ubuntu 26.04 LTS 已经发布，代号 Resolute Raccoon（坚毅浣熊），支持期为 5 年，并提供额外 5 年的安全支持，以及再额外 5 年的继续安全更新。@Appinn Ubuntu 26.04 LTS 还对新的 CPU / GPU / NPU 做了优化，并且引入了 TPM...
|
||||
|
||||
- [本周赛博领鸡蛋：4.24~4.30](https://www.appinn.com/eggs-26424/)
|
||||
本周 Epic Games 送出 1 款电脑游戏《DOOMBLADE》，以及 1 款手机游戏《911 Operator》。好评率颇高。 《DOOMBLADE》 《DOOMBLADE》是一款 2D 类银河战士恶魔城动作游戏。 在地下深处，幽影少女发现了厄运之刃。这件有自我意识的武器遭到多年封印，迫切渴...
|
||||
|
||||
- [又是 npm 包投毒，密码管理器 Bitwarden CLI 中招（放心：本体安全）](https://www.appinn.com/bitwarden-cli-npm-supply-chain-attack-2026/)
|
||||
密码管理器 Bitwarden 本体没有问题，命令行工具 @bitwarden/cli@2026.4.0 版本中招。如果你和你的 AI 不曾使用 CLI，就可以不管它。@Appinn 发生了什么？ 来自 socket.dev 的消息：攻击者入侵了 Bitwarden 的发布流程（CI/CD），把一个...
|
||||
|
||||
- [最强开源模型 DeepSeek V4 发布，1M上下文，运行成本大降](https://www.appinn.com/deepseek-v4/)
|
||||
DeepSeek V4 终于发布了，带来了 1M 上下文，代码能力明显提升，推理进入第一梯队，但知识类能力仍落后于头部闭源模型。 最重要的是：「DeepSeek-V4 开创了一种全新的注意力机制，在 token 维度进行压缩，结合 DSA 稀疏注意力（DeepSeek Sparse Attentio...
|
||||
|
||||
### 【TED Talks Daily】
|
||||
|
||||
- [What Kosovo can teach the world about freedom | Vjosa Osmani Sadriu](http://go.ted.com/vjosaosmanisadriu)
|
||||
“Truth is the real oxygen for democracy,” says Vjosa Osmani Sadriu, the 6th President of the Republic of Kosovo. As a child of war, she once longed fo...
|
||||
|
||||
### 【Slashdot】
|
||||
|
||||
- [Bitwarden CLI Is the Next Compromise In Checkmarx Supply Chain Campaign](https://it.slashdot.org/story/26/04/24/2032218/bitwarden-cli-is-the-next-compromise-in-checkmarx-supply-chain-campaign?utm_source=rss1.0mainlinkanon&utm_medium=feed)
|
||||
Longtime Slashdot reader Himmy32 writes: Socket Security published an article on the compromise of the Bitwarden CLI client, which was pushed from Bit...
|
||||
|
||||
- [Google To Invest Up To $40 Billion In Anthropic](https://tech.slashdot.org/story/26/04/24/1933253/google-to-invest-up-to-40-billion-in-anthropic?utm_source=rss1.0mainlinkanon&utm_medium=feed)
|
||||
Google plans to invest up to $40 billion more in Anthropic, starting with $10 billion now and another $30 billion tied to performance milestones. CNBC...
|
||||
|
||||
- [South Korea Police Arrest Man For Posting AI Photo of Runaway Wolf](https://yro.slashdot.org/story/26/04/24/195210/south-korea-police-arrest-man-for-posting-ai-photo-of-runaway-wolf?utm_source=rss1.0mainlinkanon&utm_medium=feed)
|
||||
South Korean police arrested a man accused of spreading an AI-generated image of an escaped wolf, after the fake photo reportedly misled authorities a...
|
||||
|
||||
- [Researchers Simulated a Delusional User To Test Chatbot Safety](https://slashdot.org/story/26/04/24/174206/researchers-simulated-a-delusional-user-to-test-chatbot-safety?utm_source=rss1.0mainlinkanon&utm_medium=feed)
|
||||
An anonymous reader quotes a report from 404 Media: I'm the unwritten consonant between breaths, the one that hums when vowels stretch thin... Thursda...
|
||||
|
||||
- [Norway Set to Become Latest Country to Ban Social Media for Under 16s](https://tech.slashdot.org/story/26/04/24/1649232/norway-set-to-become-latest-country-to-ban-social-media-for-under-16s?utm_source=rss1.0mainlinkanon&utm_medium=feed)
|
||||
Norway plans to ban social media access for children under 16 (source paywalled; alternative source), "joining a growing number of countries respondin...
|
||||
|
||||
- [Community Votes to Deny Water to Nuclear Weapons Data Center](https://news.slashdot.org/story/26/04/24/0549221/community-votes-to-deny-water-to-nuclear-weapons-data-center?utm_source=rss1.0mainlinkanon&utm_medium=feed)
|
||||
A Michigan township has voted to impose a one-year moratorium on providing water to hyperscale data centers, a move aimed at delaying a planned facili...
|
||||
|
||||
- [US Special Forces Soldier Arrested For Polymarket Bets On Maduro Raid](https://yro.slashdot.org/story/26/04/24/0539242/us-special-forces-soldier-arrested-for-polymarket-bets-on-maduro-raid?utm_source=rss1.0mainlinkanon&utm_medium=feed)
|
||||
An anonymous reader quotes a report from Wired: The Department of Justice announced Thursday that it arrested Gannon Ken Van Dyke, an enlisted member ...
|
||||
|
||||
- [Claude Is Connecting Directly To Your Personal Apps](https://tech.slashdot.org/story/26/04/24/066231/claude-is-connecting-directly-to-your-personal-apps?utm_source=rss1.0mainlinkanon&utm_medium=feed)
|
||||
Anthropic is expanding Claude's app integrations beyond work tools, adding personal-service connectors like Spotify, Uber, AllTrails, TripAdvisor, Ins...
|
||||
|
||||
- [FCC's Foreign-Made Router Ban Expands To Portable Wi-Fi Hotspot Devices](https://mobile.slashdot.org/story/26/04/24/0617244/fccs-foreign-made-router-ban-expands-to-portable-wi-fi-hotspot-devices?utm_source=rss1.0mainlinkanon&utm_medium=feed)
|
||||
The FCC has expanded its foreign-made router ban to also cover consumer Wi-Fi hotspots and LTE/5G home-internet devices, though existing products and ...
|
||||
|
||||
- [New Gas-Powered Data Centers Could Emit More Greenhouse Gases Than Entire Nations](https://hardware.slashdot.org/story/26/04/23/2110220/new-gas-powered-data-centers-could-emit-more-greenhouse-gases-than-entire-nations?utm_source=rss1.0mainlinkanon&utm_medium=feed)
|
||||
An anonymous reader quotes a report from Wired: New gas projects linked to just 11 data center campuses around the US have the potential to create mor...
|
||||
|
||||
### 【AI (artificial intelligence) | The Guardian】
|
||||
|
||||
- [Officials hugely underestimated impact of AI datacentres on UK carbon emissions](https://www.theguardian.com/technology/2026/apr/24/officials-hugely-underestimated-impact-of-ai-datacentres-on-uk-carbon-emissions)
|
||||
Revised figures increase fears about energy-intensive datacentres worsening climate emergencyThe UK government vastly underestimated the climate impac...
|
||||
|
||||
- [Democratic Maine governor vetoes first US state freeze on new datacenters](https://www.theguardian.com/us-news/2026/apr/24/maine-governor-blocks-datacenter-moratorium)
|
||||
Janet Mills says moratorium would’ve been ‘appropriate’ if it didn’t interfere with ongoing datacenter project in MaineThe Democratic governor of Main...
|
||||
|
||||
- [‘Look, no hands’: China chases the driverless dream at Beijing car show](https://www.theguardian.com/technology/2026/apr/24/china-chases-driverless-dream-beijing-car-show-ai)
|
||||
As domestic sales slow, manufacturers are investing in AI and seeking growth in technology and in overseas marketsAt the world’s biggest car fair, whi...
|
||||
|
||||
- [Grok tells researchers pretending to be delusional ‘drive an iron nail through the mirror while reciting Psalm 91 backwards’](https://www.theguardian.com/technology/2026/apr/24/musk-grok-x-ai-researchers-delusional-advice-inputs)
|
||||
Elon Musk’s AI chatbot ‘extremely validating’ of delusional inputs and often went further, ‘elaborating new material’, study findsFollow our Australia...
|
||||
|
||||
- [Will the backlash against AI turn violent? – podcast](https://www.theguardian.com/news/audio/2026/apr/24/will-the-backlash-against-ai-turn-violent-podcast)
|
||||
An attack on the home of OpenAI’s CEO Sam Altman – and on the company’s headquarters – has led to concerns the backlash against AI could become violen...
|
||||
|
||||
### 【WSJ.com: World News】
|
||||
|
||||
- [Persian Gulf Oil Damage Will Ripple Long Past the End of the War](https://www.wsj.com/world/middle-east/persian-gulf-oil-damage-will-ripple-long-past-the-end-of-the-war-845acf09)
|
||||
Even if the strait opened tomorrow, the hit to the global economy would be long lasting....
|
||||
|
||||
- [The Priceless Treasures Fueling Sudan’s Bitter Civil War](https://www.wsj.com/world/africa/the-priceless-treasures-fueling-sudans-bitter-civil-war-2acde21c)
|
||||
Rebel fighters are targeting the country’s rich cultural history and selling valuable artifacts to the highest bidder in the illicit international art...
|
||||
|
||||
- [An Iranian Ship Tried to Slip Past the Blockade. A U.S. Destroyer Chased It Down.](https://www.wsj.com/world/middle-east/iran-ships-us-blockade-34a5f704)
|
||||
Hundreds of ghost-fleet vessels are playing a game of cat-and-mouse as the U.S. tries to lock down Tehran’s oil trade and pressure it to accept Presid...
|
||||
|
||||
35
wiki/concepts/Atomic-Commit.md
Normal file
35
wiki/concepts/Atomic-Commit.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: "Atomic Commit"
|
||||
type: concept
|
||||
tags: ["git", "code-quality", "delivery-traceability"]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Atomic Commit（原子提交）是一种 Git 提交粒度原则——每次提交仅包含一个逻辑变更单元（一个清晰的改动），易于审查、回滚和溯源，不捆绑多个不相关的变更。
|
||||
|
||||
## Characteristics
|
||||
|
||||
- **单一职责**：一个 commit = 一个清晰的改动
|
||||
- **可独立回滚**：回滚一个 commit 不会影响其他功能的正常运行
|
||||
- **可独立审查**：reviewer 能在短时间内理解单个 commit 的意图
|
||||
- **易于溯源**：通过 commit message 快速定位引入特定行为的 ticket
|
||||
|
||||
## Anti-patterns
|
||||
|
||||
| 反模式 | 描述 | 风险 |
|
||||
|--------|------|------|
|
||||
| Mega commit | 一次性提交大量不相关变更 | review 成本高；回滚连带损伤 |
|
||||
| WIP commit | 包含 work-in-progress 代码的提交 | 污染历史，难以理解 |
|
||||
| Fixup commit | 在 review 过程中不断追加修改 | 历史难以重建 |
|
||||
| Bundled commit | 将多个功能捆在一个 commit 里 | 拆分困难，回滚粒度过粗 |
|
||||
|
||||
## Relationship to Branch Strategy
|
||||
|
||||
Atomic Commit 与 [[Branch-Strategy]] 共同构成 [[Jira-Git-Traceability]] 的基础：
|
||||
- Branch 隔离不同任务的工作
|
||||
- 每个 branch 内的 commit 进一步原子化
|
||||
|
||||
## Sources
|
||||
- [[project-management-jira-workflow-steward]]
|
||||
39
wiki/concepts/Branch-Strategy.md
Normal file
39
wiki/concepts/Branch-Strategy.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "Branch Strategy"
|
||||
type: concept
|
||||
tags: ["git", "workflow", "delivery-traceability"]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Branch Strategy（分支策略）是一套基于变更类型的分支分层管理模型，通过规范化分支命名和来源规则，确保各类型的代码变更在正确的上下文中开发、审查和合并。
|
||||
|
||||
## Branch Types
|
||||
|
||||
| 类型 | 模式 | 来源分支 | 目标分支 | 典型场景 |
|
||||
|------|------|----------|----------|----------|
|
||||
| Feature | `feature/JIRA-ID-description` | develop | develop | 新产品或平台功能 |
|
||||
| Bugfix | `bugfix/JIRA-ID-description` | develop | develop | 非关键缺陷修复 |
|
||||
| Hotfix | `hotfix/JIRA-ID-description` | main | main | 关键生产环境修复 |
|
||||
| Refactor | `feature/JIRA-ID-description` | develop | develop | 结构清理（需关联 Jira 任务） |
|
||||
| Docs | `feature/JIRA-ID-description` | develop | develop | 文档更新（需关联 Jira 任务） |
|
||||
| Tests | `bugfix/JIRA-ID-description` | develop | develop | 回归测试（需关联 Jira 任务） |
|
||||
| Config | `feature/JIRA-ID-description` | develop | develop | 配置或工作流策略变更 |
|
||||
| Dependencies | `bugfix/JIRA-ID-description` | develop | develop | 依赖或平台升级 |
|
||||
| Release | `release/version` | develop | main | 发布准备 |
|
||||
|
||||
## Protected Branches
|
||||
|
||||
- `main`：始终生产就绪；所有合并必须经过 PR review
|
||||
- `develop`：持续集成的集成分支；feature/bugfix 从其拉取
|
||||
- `release/*`：发布准备分支；仍需关联 release ticket 或变更控制项
|
||||
|
||||
## Relationship to Other Concepts
|
||||
|
||||
- [[Atomic-Commit]]：在 branch 内部进一步原子化 commit
|
||||
- [[Jira-Git-Traceability]]：每个 branch 必须包含 Jira ID 作为唯一标识
|
||||
- [[Jira-Gate]]：branch 创建前必须验证 Jira Task 存在
|
||||
|
||||
## Sources
|
||||
- [[project-management-jira-workflow-steward]]
|
||||
50
wiki/concepts/ChinaLaborLawCompliance.md
Normal file
50
wiki/concepts/ChinaLaborLawCompliance.md
Normal file
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: "China Labor Law Compliance（中国劳动法合规）"
|
||||
type: concept
|
||||
tags: [compliance, labor-law, hr, china]
|
||||
sources: [recruitment-specialist]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## 定义
|
||||
中国劳动法合规是指在招聘、入职、管理、离职全流程中，遵守《中华人民共和国劳动合同法》、《就业促进法》、《个人信息保护法》（PIPL）等法律法规的一系列要求。
|
||||
|
||||
## 在 [[Recruitment Specialist Agent]] 中的核心模块
|
||||
|
||||
### 劳动合同法要点
|
||||
- **合同签订**：入职30天内必须签订书面劳动合同，违者需支付双倍工资
|
||||
- **合同类型**：固定期限、无固定期限、项目型
|
||||
- **连续两次固定期限合同后**：员工有权要求签订无固定期限合同
|
||||
|
||||
### 试用期规定
|
||||
- 合同期3个月~1年：试用期 ≤ 1个月
|
||||
- 合同期1年~3年：试用期 ≤ 2个月
|
||||
- 合同期3年及以上：试用期 ≤ 6个月
|
||||
- 试用期工资 ≥ 约定工资的80% 且 ≥ 当地最低工资
|
||||
- 同一员工只能设定一次试用期
|
||||
|
||||
### 五险一金
|
||||
- **五险**：养老保险、医疗保险、失业保险、工伤保险、生育保险
|
||||
- **一金**：住房公积金
|
||||
- 入职30天内必须完成社保登记和缴纳
|
||||
|
||||
### 竞业限制
|
||||
- 期限 ≤ 2年
|
||||
- 补偿金通常 ≥ 离职前12个月平均月薪的30%
|
||||
- 拖欠超过3个月，员工有权解除竞业义务
|
||||
|
||||
### 经济补偿（N+1）
|
||||
- **N**：每满一年支付一个月工资
|
||||
- **N+1**：未提前30天通知，额外支付一个月工资
|
||||
- **违法解除**：2N 赔偿
|
||||
- 月工资上限：当地社会平均工资的3倍，最长计算12年
|
||||
|
||||
## 合规红线
|
||||
- 禁止就业歧视（性别、年龄、婚姻状况、民族、宗教）
|
||||
- 背景调查需候选人书面授权
|
||||
- 候选人个人信息收集须符合 PIPL
|
||||
- 提前排查竞业限制，避免招用有竞业义务的人员
|
||||
|
||||
## 连接
|
||||
- [[Recruitment Specialist Agent]] — 内置劳动法合规知识库
|
||||
- [[Recruitment Specialist Agent]] — 入职 SOP 中的合同签署和社保登记流程
|
||||
47
wiki/concepts/Delivery-Traceability.md
Normal file
47
wiki/concepts/Delivery-Traceability.md
Normal file
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: "Delivery Traceability"
|
||||
type: concept
|
||||
tags: ["delivery", "traceability", "project-management", "audit"]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Delivery Traceability（交付可追溯性）是指从业务需求到代码发布全链路的可重建、可审计交付记录体系，使团队能在几分钟内重建"从需求到已发布代码"的完整路径，而非花费数小时。
|
||||
|
||||
## The Five Links
|
||||
|
||||
| 环节 | 关键问题 | 可追溯性价值 |
|
||||
|------|----------|------------|
|
||||
| **Jira Task** | 这个需求从哪里来？ | 需求来源记录 |
|
||||
| **Branch** | 这段代码在哪个隔离环境开发？ | 隔离性保证 |
|
||||
| **Commit** | 这个改动具体做了什么？ | 原子粒度的变更记录 |
|
||||
| **Pull Request** | 谁审查了这次变更？ | Review 责任链 |
|
||||
| **Release** | 这个功能何时上线？ | 发布时间线记录 |
|
||||
|
||||
## Two Modes of Traceability
|
||||
|
||||
### Prospective Traceability（前向追溯）
|
||||
从 Jira 任务 → 代码 → 发布，确保需求被完整实现。用于：进度跟踪、变更影响分析。
|
||||
|
||||
### Retrospective Traceability（回溯追溯）
|
||||
从已发布代码 → Jira 任务 → 需求来源，用于：事故溯源、审计合规、回滚决策。
|
||||
|
||||
## Traceability vs. Bureaucracy
|
||||
|
||||
[[Jira Workflow Steward]] 的核心观点：**Jira-linked commits 是质量工具，而非合规打勾**。
|
||||
|
||||
当开发者理解可追溯性的实际价值（review 加速、发布说明自动生成、事故 10 分钟内定位）时，遵循规范的阻力会显著降低。
|
||||
|
||||
## Success Metrics
|
||||
|
||||
- 从 Jira + Git 历史重建发布说明：< 10 分钟
|
||||
- 定位引入特定行为的 ticket 和 commit：< 5 分钟
|
||||
- 回滚操作：原子 commit 使回滚低风险
|
||||
|
||||
## Relationship to GitOps
|
||||
|
||||
Delivery Traceability 关注业务需求到代码交付的全链路，[[GitOps]] 关注基础设施声明到部署的自动化调和。两者共同构成完整的软件交付可追溯性体系。
|
||||
|
||||
## Sources
|
||||
- [[project-management-jira-workflow-steward]]
|
||||
65
wiki/concepts/Gitmoji-Commit.md
Normal file
65
wiki/concepts/Gitmoji-Commit.md
Normal file
@@ -0,0 +1,65 @@
|
||||
---
|
||||
title: "Gitmoji Commit"
|
||||
type: concept
|
||||
tags: ["git", "gitmoji", "code-quality"]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Gitmoji Commit 是一种提交规范，使用标准化 Emoji（Gitmoji）作为提交类型的视觉前缀，使开发者能在 git log 中通过 Emoji 快速识别变更意图。
|
||||
|
||||
## Format
|
||||
|
||||
```
|
||||
<Gitmoji> JIRA-ID: short description
|
||||
```
|
||||
|
||||
示例：
|
||||
- `✨ JIRA-214: add SSO login flow`
|
||||
- `🐛 JIRA-315: fix token refresh race`
|
||||
- `♻️ JIRA-522: refactor audit service boundaries`
|
||||
- `📚 JIRA-623: document API error catalog`
|
||||
- `🧪 JIRA-724: add session timeout regression tests`
|
||||
- `🔧 JIRA-811: add branch policy validation`
|
||||
- `📦 JIRA-902: upgrade GitHub Actions versions`
|
||||
|
||||
## Official Gitmoji Catalog
|
||||
|
||||
| Emoji | 含义 | 使用场景 |
|
||||
|-------|------|----------|
|
||||
| ✨ | 新功能 | 新增 agent、catalog 功能 |
|
||||
| 🐛 | 缺陷修复 | bug fix |
|
||||
| ♻️ | 重构 | 代码结构优化 |
|
||||
| 📚 | 文档 | 仅限现有功能/贡献指南的文档更新 |
|
||||
| 🧪 | 测试 | 测试编写或更新 |
|
||||
| 💄 | 样式 | UI/样式调整（不改变行为） |
|
||||
| 🔧 | 配置 | 工作流、CI/CD、配置变更 |
|
||||
| 📦 | 依赖 | 依赖或平台升级 |
|
||||
| 🚀 | 部署 | 部署相关变更 |
|
||||
|
||||
## Gitmoji Selection Principle
|
||||
|
||||
> 优先选择反映**实际变更类型**的 Gitmoji，而非个人偏好。
|
||||
|
||||
特殊情况：
|
||||
- 为新 agent（全新 catalog 功能）→ 优先使用 `✨` 而非 `📚`（因为 Gitmoji 将 `✨` 定义为新功能）
|
||||
- 仅更新现有 agent 文档或贡献指南 → 使用 `📚`
|
||||
|
||||
## Automated Validation
|
||||
|
||||
通过 commit-msg hook 自动验证格式：
|
||||
|
||||
```bash
|
||||
commit_regex='^(🚀|✨|🐛|♻️|📚|🧪|💄|🔧|📦) [A-Z]+-[0-9]+: .+$'
|
||||
```
|
||||
|
||||
不符合格式的提交将被拒绝。
|
||||
|
||||
## Official References
|
||||
|
||||
- Primary: [gitmoji.dev](https://gitmoji.dev/)
|
||||
- Source of truth: [github.com/carloscuesta/gitmoji](https://github.com/carloscuesta/gitmoji)
|
||||
|
||||
## Sources
|
||||
- [[project-management-jira-workflow-steward]]
|
||||
50
wiki/concepts/Innovation-Pipeline.md
Normal file
50
wiki/concepts/Innovation-Pipeline.md
Normal file
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: "Innovation Pipeline"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Innovation Pipeline（创新管道）是 [[Strategic-Portfolio-Management]] 中的一个特殊项目层级，专门用于管理实验性、创新性项目。与 Tier 1/2 追求确定性回报不同，Innovation Pipeline 项目的核心价值是学习而非短期财务回报。
|
||||
|
||||
## Position in Portfolio Architecture
|
||||
|
||||
```
|
||||
Strategic Portfolio
|
||||
├── Tier 1 Projects (Strategic Priority)
|
||||
│ └── 高投资，高确定性战略回报
|
||||
├── Tier 2 Projects (Growth Initiatives)
|
||||
│ └── 中等投资，中等增长回报
|
||||
└── Innovation Pipeline
|
||||
└── 低投资，高学习价值，失败是预期结果
|
||||
```
|
||||
|
||||
## Key Characteristics
|
||||
|
||||
- **Learning Objectives**：项目目标设定为学习而非回报
|
||||
- **Lower Resource Commitment**：资源投入相对有限
|
||||
- **Higher Risk Tolerance**：失败被视为有价值的数据点
|
||||
- **Capability Development**：驱动组织能力和技术探索
|
||||
- **Technology Adoption**：新技术和方法的试验田
|
||||
|
||||
## Relationship to Other Concepts
|
||||
|
||||
- 属于 [[Strategic-Portfolio-Management]] 的组成部分
|
||||
- 支持 [[Resource-Allocation]] 中的能力建设优先级
|
||||
- 与 [[Risk-Balancing]] 密切相关——Innovation Pipeline 是风险敞口的主要来源
|
||||
|
||||
## In Studio Producer Framework
|
||||
|
||||
在 [[Project-Management-Studio-Producer]] 的 Strategic Portfolio Plan 模板中，Innovation Pipeline 是独立章节，包含：
|
||||
- 实验性举措和学习目标
|
||||
- 技术采纳和能力发展
|
||||
- 失败容错机制设计
|
||||
|
||||
## Aliases
|
||||
- Experimental Portfolio
|
||||
- R&D Pipeline
|
||||
- Innovation Portfolio
|
||||
- Learning Portfolio
|
||||
44
wiki/concepts/Jira-Gate.md
Normal file
44
wiki/concepts/Jira-Gate.md
Normal file
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: "Jira Gate"
|
||||
type: concept
|
||||
tags: ["project-management", "jira", "workflow", "quality-gate"]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Jira Gate（Jira 门控）是 [[Jira Workflow Steward]] Agent 实施的一项强制性工作流规则：**在没有有效 Jira Task ID 的前提下，不生成任何分支名、提交信息或 Git 工作流建议**。Jira Task ID 是所有交付输出的前提条件。
|
||||
|
||||
## Rules
|
||||
|
||||
1. **Never generate without Jira ID**：分支名、commit message、PR 标题均必须包含有效 Jira Task ID
|
||||
2. **Exact preservation**：严格使用 Jira ID 原样，不得发明、规范或猜测缺失的 ticket 引用
|
||||
3. **Prompt for ID, don't guess**：若 Jira 任务缺失，则请求补充，而非自动创建 ID
|
||||
|
||||
> 若 Jira 任务缺失，询问：`Please provide the Jira task ID associated with this work (e.g. JIRA-123).`
|
||||
|
||||
## External Prefix Handling
|
||||
|
||||
若外部系统（如 AI 编码 agent）添加了外层前缀，分支名内部仍需保持仓库原生格式：
|
||||
|
||||
- ✅ `codex/feature/JIRA-214-add-sso-login`（仓库格式在外部包装内保持不变）
|
||||
- ❌ `feature/JIRA-214-add-sso-login` → `codex/JIRA-214-add-sso-login`（丢失仓库类型信息）
|
||||
|
||||
## Gate Position in Workflow
|
||||
|
||||
```
|
||||
[Request] → [Jira Gate: 要求 Jira ID] → [Branch Strategy] → [Atomic Commits] → [PR Template] → [Release]
|
||||
↓
|
||||
[无 Jira ID → 停止并请求]
|
||||
```
|
||||
|
||||
Jira Gate 位于整个交付链路的最前端，是第一道质量门。
|
||||
|
||||
## Relationship to Other Concepts
|
||||
|
||||
- [[Jira-Git-Traceability]]：Jira Gate 是 Jira-Git Traceability 的第一步门控
|
||||
- [[Branch-Strategy]]：Gate 通过后才进入分支策略流程
|
||||
- [[Pull-Request-Governance]]：PR 合并同样需要 Jira ID 验证
|
||||
|
||||
## Sources
|
||||
- [[project-management-jira-workflow-steward]]
|
||||
39
wiki/concepts/Jira-Git-Traceability.md
Normal file
39
wiki/concepts/Jira-Git-Traceability.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "Jira-Git Traceability"
|
||||
type: concept
|
||||
tags: ["project-management", "jira", "git-workflow", "delivery-traceability"]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Jira-Git Traceability（ Jira-Git 可追溯性）是指通过 Jira Task ID 将软件交付链路中的 Jira 任务、分支、提交、Pull Request 和 Release 五个环节串联为完整可追溯记录的工作流实践。其核心原则为：**若某项变更无法从 Jira 追踪到分支、提交、PR 直至发布，则该工作流视为不完整**。
|
||||
|
||||
## Core Components
|
||||
|
||||
| 环节 | 要求 | 工具/模式 |
|
||||
|------|------|----------|
|
||||
| Jira Task | 所有 Git 工作流的唯一锚点 | Jira Gate 强制前置 |
|
||||
| Branch | 必须包含 Jira ID：`feature/JIRA-214-xxx` | 分支策略 |
|
||||
| Commit | 必须包含 Jira ID：`<Gitmoji> JIRA-214: description` | Gitmoji Commit 规范 |
|
||||
| Pull Request | PR 标题必须包含 Jira ID | PR 模板 |
|
||||
| Release | 发布记录必须关联 Jira 任务或变更控制项 | Release Branch |
|
||||
|
||||
## Why It Matters
|
||||
|
||||
1. **Review Speed**：reviewer 可在 5 秒内通过 commit subject 识别变更类型和 ticket 上下文
|
||||
2. **Release Notes**：从 Jira 和 Git 历史可在 10 分钟内重建发布说明
|
||||
3. **Incident Forensics**：事故溯源时可在分钟内定位引入行为的 ticket 和 commit
|
||||
4. **Audit Readiness**：合规环境中，需求到代码的完整链路是审计强制要求
|
||||
5. **Atomic Reverts**：commit 原子化且 purpose-labeled，回滚操作低风险
|
||||
|
||||
## Relationship to GitOps
|
||||
|
||||
Jira-Git Traceability 是 GitOps 在项目管理层面的扩展：
|
||||
- **GitOps** 关注：基础设施声明 → Git → 自动调和（环境始终与 Git 同步）
|
||||
- **Jira-Git Traceability** 关注：需求（Jira）→ 代码（Git）→ 交付（Release）全链路可追溯
|
||||
|
||||
两者互补：GitOps 确保基础设施状态，Jira-Git Traceability 确保业务需求到代码的双向可追溯。
|
||||
|
||||
## Sources
|
||||
- [[project-management-jira-workflow-steward]]（主要来源）
|
||||
29
wiki/concepts/Liquid-Glass-Design-System.md
Normal file
29
wiki/concepts/Liquid-Glass-Design-System.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "Liquid Glass Design System"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: [visionos-spatial-engineer]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
Apple visionOS 26 引入的核心视觉设计语言，通过透明材质实现深度感知和空间沉浸感。Liquid Glass 设计系统让 UI 元素呈现出类似玻璃的透明、折射和光影效果，同时自适应 light/dark 环境变化和周围内容。
|
||||
|
||||
## Core Characteristics
|
||||
- **Translucent Materials（透明材质）**：UI 元素呈现玻璃般的透明效果，可透视背后的 3D 空间内容
|
||||
- **Adaptive Lighting（自适应光效）**：根据环境光照条件动态调整透明度和反射效果
|
||||
- **Depth Perception（深度感知）**：通过透明层级传达 UI 元素在 Z 轴上的相对位置
|
||||
- **Contextual Adaptation（内容自适应）**：透明效果根据周围 3D 内容动态调整，确保可读性和美观性
|
||||
|
||||
## Implementation Technologies
|
||||
- **SwiftUI glassBackgroundEffect**：实现毛玻璃透明背景的 SwiftUI modifier
|
||||
- **RealityKit Materials**：RealityKit 中的物理材质系统支持 Liquid Glass 效果
|
||||
- **Metal Shader Framework**：底层 GPU 渲染支持高性能透明效果计算
|
||||
|
||||
## Related Concepts
|
||||
- [[Spatial Layouts]]：Liquid Glass UI 在 3D 空间中的布局管理
|
||||
- [[Multi-Window Architecture]]：多窗口场景下 Liquid Glass 效果的一致性
|
||||
- [[Glass Background Effects]]：具体实现透明效果的技术手段
|
||||
|
||||
## Sources
|
||||
- [[visionos-spatial-engineer]] — visionOS Spatial Engineer Agent 角色定义
|
||||
29
wiki/concepts/Multi-Window-Architecture.md
Normal file
29
wiki/concepts/Multi-Window-Architecture.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "Multi-Window Architecture"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: [visionos-spatial-engineer]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
visionOS 应用的多窗口管理模式，基于 WindowGroup 场景类型，支持 single-instance 窗口、volumetric 展示和空间场景管理。
|
||||
|
||||
## Window Types
|
||||
- **Unique Windows（单实例窗口）**：应用主窗口，每次只存在一个实例
|
||||
- **Volumetric Presentations（空间展示）**：在 3D volume 内呈现的辅助内容窗口
|
||||
- **Spatial Scenes（空间场景）**：完整的 3D 空间应用场景定义
|
||||
|
||||
## Core Patterns
|
||||
- **WindowGroup Management**：通过 WindowGroup 管理同类型窗口的生命周期
|
||||
- **Glass Background Effects**：每个窗口默认带有 Liquid Glass 风格的毛玻璃背景
|
||||
- **Spatial Presentation Hierarchy**：窗口之间的空间层级关系管理
|
||||
- **Presentation State**：SwiftUI 状态驱动的窗口展示模式切换
|
||||
|
||||
## Related Concepts
|
||||
- [[Spatial Widgets]]：与主窗口协同工作的空间小组件
|
||||
- [[Liquid Glass Design System]]：多窗口场景下的统一视觉语言
|
||||
- [[Multi-Window Architecture]] — 见本文
|
||||
|
||||
## Sources
|
||||
- [[visionos-spatial-engineer]] — visionOS Spatial Engineer Agent 角色定义
|
||||
91
wiki/concepts/National-Annex.md
Normal file
91
wiki/concepts/National-Annex.md
Normal file
@@ -0,0 +1,91 @@
|
||||
---
|
||||
title: "National Annex"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- National Annex to Eurocode（Eurocode 国家附录）
|
||||
- NDPs（Nationally Determined Parameters，国家确定参数）
|
||||
- 欧洲规范国家附录
|
||||
- 欧盟规范本地化修订
|
||||
|
||||
## Definition
|
||||
|
||||
National Annex（国家附录）是各 Eurocode 成员国对 EN 1990–1999 系列规范的本地化修订文件，通过国家确定参数（NDPs）改变 Eurocode 默认值，从而在 Eurocode 框架内实现各国不同的安全等级和设计偏好。National Annex 是 Eurocode 体系内**规范冲突的主要来源**。
|
||||
|
||||
## What National Annexes Modify
|
||||
|
||||
### 1. Nationally Determined Parameters (NDPs)
|
||||
Eurocode 规范中的部分参数由各成员国自行确定，包括：
|
||||
|
||||
| 参数类型 | 示例 | 影响 |
|
||||
|---------|------|------|
|
||||
| 荷载分项系数 γ | Eurocode 默认 γG=1.35, γQ=1.5 | 英国 NA 可能调高 γG |
|
||||
| 组合系数 ψ | Eurocode 默认 ψ0=0.7（办公室活荷载） | 各国可能不同 |
|
||||
| 可靠度系数 γM | Eurocode 默认 γM0=1.0, γM1=1.0 | 影响构件抗力 |
|
||||
| 安全等级 | 从 RC1/RC2/RC3 选择 | 影响 γF 和 γM |
|
||||
| 地震重要性系数 γI | EN 1998 Default = 1.0 | 各国可调高 |
|
||||
| 地震谱形状 | 与 EN 1998-1 附录相同 | 部分国家有修订 |
|
||||
|
||||
### 2. Informative Annexes
|
||||
- Eurocode 各部分包含"资料性附录"，各国可选择采纳或废弃
|
||||
|
||||
### 3. National Deviations
|
||||
- 超出 Eurocode 框架的额外要求（如特定材料标准、构造细节）
|
||||
|
||||
## Major National Annexes
|
||||
|
||||
| 国家 | 缩写 | 关键差异 |
|
||||
|------|------|---------|
|
||||
| United Kingdom | UK NA to BS EN | 风荷载高度系数（UK 地形更粗糙）、地震分区 |
|
||||
| Germany | NA DE | DIN 标准兼容性处理、高延性 DCH 要求严格 |
|
||||
| France | NF EN | 混凝土抗压强度等级（法标与欧标衔接） |
|
||||
| Netherlands | NTA | 地基与岩土设计有特殊附录 |
|
||||
| Sweden | EKS | 风荷载暴露系数（瑞典多森林地形） |
|
||||
| Norway | NA NO | 地震要求（挪威北部有地震风险） |
|
||||
|
||||
## Why National Annexes Create Conflicts
|
||||
|
||||
**同一结构在两个国家可能需要不同设计：**
|
||||
|
||||
```
|
||||
场景：钢框架建筑，巴黎 vs 伦敦
|
||||
|
||||
设计输入：
|
||||
- 结构系统：钢框架
|
||||
- 跨度：8m
|
||||
- 活荷载：5 kN/m²
|
||||
|
||||
英国 (UK NA to BS EN 1993-1-1)：
|
||||
- γG = 1.35, γQ = 1.50
|
||||
- 截面分类界限按 UK NA 修正
|
||||
- 风荷载：UK NA 按暴露度 C（郊区地形）
|
||||
|
||||
法国 (NF EN)：
|
||||
- γG = 1.35, γQ = 1.50（与 EN 默认相同）
|
||||
- 截面分类按 EN 默认值
|
||||
- 风荷载：NF EN 规定暴露类别和系数
|
||||
|
||||
结果：相同结构在 UK 和 FR 可能需要不同构件尺寸
|
||||
```
|
||||
|
||||
## Multi-Standard Projects and National Annexes
|
||||
|
||||
在涉及 Eurocode + 另一标准（如 ACI 318）的多标准项目中，National Annexes 的处理流程：
|
||||
|
||||
1. **识别所有适用的 National Annex**（项目所在国 + 业主所在国）
|
||||
2. **列出 NDPs 与 EN 默认值的偏差**
|
||||
3. **评估偏差对设计结果的影响**
|
||||
4. **在 Basis of Design 中记录最终采用的 NDPs**
|
||||
5. **向 AHJ（主管当局）确认接受哪些 National Annex 版本**
|
||||
|
||||
## Usage in Civil Engineer Agent
|
||||
|
||||
Civil Engineer Agent 处理 Eurocode 项目时，**必须**在每个计算包开头注明：
|
||||
1. 所采用的 Eurocode EN 标准编号和版本年份
|
||||
2. 所适用的 National Annex（如 NA to BS EN 1993-1-1）
|
||||
3. 所有与 EN 默认值不同的 NDPs（列表形式）
|
||||
4. **铁律**：绝不在 Eurocode 公式中混入 ACI/AISC 的分项系数
|
||||
43
wiki/concepts/Portfolio-ROI.md
Normal file
43
wiki/concepts/Portfolio-ROI.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "Portfolio ROI"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Portfolio ROI（组合投资回报率）是衡量组合层面投资效益的核心财务指标，定义为组合整体收益与总投资成本的比率。在 [[Project-Management-Studio-Producer]] 的框架中，Portfolio ROI 是组合管理的北极星指标，设定基准为 **≥ 25%**。
|
||||
|
||||
## Calculation Framework
|
||||
|
||||
```
|
||||
Portfolio ROI = (组合总收益 - 组合总投资成本) / 组合总投资成本 × 100%
|
||||
```
|
||||
|
||||
## Portfolio ROI vs. Project ROI
|
||||
|
||||
| Dimension | Project ROI | Portfolio ROI |
|
||||
|-----------|-------------|--------------|
|
||||
| Scope | 单个项目 | 组合整体 |
|
||||
| Time | 项目周期 | 跨项目周期 |
|
||||
| Metrics | 范围/时间/成本 | 战略价值实现率 |
|
||||
| Focus | 执行效率 | 资源配置效率 |
|
||||
| Target | 交付成功 | 商业目标实现 |
|
||||
|
||||
## Key Influencing Factors
|
||||
|
||||
- **Tier 1 项目**：战略优先级项目，高投资高预期回报
|
||||
- **Tier 2 项目**：增长型项目，中等投资中等回报
|
||||
- **Innovation Pipeline**：实验性项目，低投资学习导向
|
||||
- **Risk-Adjusted Returns**：风险调整后的预期回报
|
||||
|
||||
## Tracking in Strategic Portfolio Management
|
||||
|
||||
在 [[Project-Management-Studio-Producer]] 的四阶段工作流中，Portfolio ROI 追踪属于"Step 4: Performance Management and Strategic Optimization"阶段，通过 Strategic Portfolio Review 模板进行季度复盘。
|
||||
|
||||
## Aliases
|
||||
- Return on Portfolio Investment
|
||||
- Portfolio Performance
|
||||
- Investment Efficiency
|
||||
60
wiki/concepts/Pull-Request-Governance.md
Normal file
60
wiki/concepts/Pull-Request-Governance.md
Normal file
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: "Pull Request Governance"
|
||||
type: concept
|
||||
tags: ["git", "code-review", "workflow", "delivery-traceability"]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Pull Request Governance（PR 治理）是通过标准化 PR 模板、安全审查要求、风险记录和强制审查流程，保护分支合并质量的工作流规范。
|
||||
|
||||
## Mandatory PR Scenarios
|
||||
|
||||
以下场景的合并**必须**经过 PR review：
|
||||
- 合并到 `main`
|
||||
- 合并到 `release/*`
|
||||
- 大型重构
|
||||
- 关键基础设施变更
|
||||
- 认证、授权、基础设施、敏感数据处理相关变更
|
||||
|
||||
## PR Template Structure
|
||||
|
||||
标准 PR 模板包含：
|
||||
|
||||
```markdown
|
||||
## What does this PR do?
|
||||
Implements **JIRA-214** by adding the SSO login flow...
|
||||
|
||||
## Jira Link
|
||||
- Ticket: JIRA-214
|
||||
- Branch: feature/JIRA-214-add-sso-login
|
||||
|
||||
## Change Summary
|
||||
- Add SSO callback controller and provider wiring
|
||||
- Add regression coverage for expired refresh tokens
|
||||
- Document the new login setup path
|
||||
|
||||
## Risk and Security Review
|
||||
- Auth flow touched: yes
|
||||
- Secret handling changed: no
|
||||
- Rollback plan: revert the branch and disable the provider flag
|
||||
|
||||
## Testing
|
||||
- Unit tests: passed
|
||||
- Integration tests: passed in staging
|
||||
- Manual verification: login and logout flow verified in staging
|
||||
```
|
||||
|
||||
## Security Discipline
|
||||
|
||||
- **No secrets in PR**：凭证、token、客户数据严禁出现在 PR 标题、描述或 diff 中
|
||||
- **Explicit validation scope**：明确说明哪些环节经过测试、哪些未经测试
|
||||
- **Security review mandatory**：认证、授权、基础设施、敏感数据处理变更必须经过安全审查
|
||||
|
||||
## Rollback Readiness
|
||||
|
||||
每个 PR 必须包含回滚计划，确保回滚操作低风险、低影响。
|
||||
|
||||
## Sources
|
||||
- [[project-management-jira-workflow-steward]]
|
||||
29
wiki/concepts/RealityKit-SwiftUI-Integration.md
Normal file
29
wiki/concepts/RealityKit-SwiftUI-Integration.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "RealityKit-SwiftUI Integration"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: [visionos-spatial-engineer]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
Apple 提供的 RealityKit 3D 渲染引擎与 SwiftUI 声明式 UI 框架之间的深度集成模式，允许开发者用 SwiftUI 语法声明式地构建 3D 空间界面。
|
||||
|
||||
## Core Integration Patterns
|
||||
- **@Observable Entities**：RealityKit 实体实现 @Observable 协议，与 SwiftUI 视图自动双向绑定
|
||||
- **Direct Gesture Handling**：SwiftUI 手势（Gesture）直接作用于 RealityKit 实体，无需中间层
|
||||
- **ViewAttachmentComponent**：将 SwiftUI 视图作为 component 附加到 RealityKit 实体
|
||||
- **EntityManager Integration**：通过 SwiftUI Environment 访问 EntityManager 实例
|
||||
|
||||
## Implementation Benefits
|
||||
- **Declarative 3D（声明式 3D）**：用 SwiftUI 视图语法替代传统 Entity-Component 模式
|
||||
- **State Synchronization（状态同步）**：SwiftUI @State/@Binding 与 RealityKit 实体属性自动同步
|
||||
- **Reduced Boilerplate（减少样板代码）**：相比纯 RealityKit 开发，集成模式显著减少代码量
|
||||
|
||||
## Related Concepts
|
||||
- [[SwiftUI Volumetric APIs]]：基于 RealityKit-SwiftUI 集成的上层 API 集
|
||||
- [[Spatial Layouts]]：集成后的 3D 内容在空间中的布局管理
|
||||
- [[Multi-Window Architecture]]：集成模式在多窗口场景下的应用
|
||||
|
||||
## Sources
|
||||
- [[visionos-spatial-engineer]] — visionOS Spatial Engineer Agent 角色定义
|
||||
43
wiki/concepts/RecruitmentFunnelAnalyzer.md
Normal file
43
wiki/concepts/RecruitmentFunnelAnalyzer.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "Recruitment Funnel Analyzer（招聘漏斗分析）"
|
||||
type: concept
|
||||
tags: [recruitment, analytics, data-driven]
|
||||
sources: [recruitment-specialist]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## 定义
|
||||
招聘漏斗分析是一种数据驱动方法，通过追踪从职位发布到试用期通过的全链路各环节转化率，识别招聘瓶颈并持续优化招聘效率和 ROI。
|
||||
|
||||
## 在 [[Recruitment Specialist Agent]] 中的实现
|
||||
|
||||
### 漏斗模型
|
||||
```
|
||||
职位曝光 → 投递量 → 简历通过 → 初试 → 复试 → 终面 → 发 offer → offer 接受 → 入职 → 试用期通过
|
||||
```
|
||||
|
||||
### 关键指标
|
||||
| 指标 | 计算方式 |
|
||||
|------|---------|
|
||||
| 简历投递率 | 投递数 / 曝光量 × 100% |
|
||||
| 简历通过率 | 通过数 / 投递数 × 100% |
|
||||
| 面试到场率 | 实到人数 / 邀约人数 × 100% |
|
||||
| offer 接受率 | 接受数 / 发出数 × 100% |
|
||||
| 入职率 | 入职数 / offer接受数 × 100% |
|
||||
| 试用期留存率 | 试用期通过数 / 入职数 × 100% |
|
||||
| 总体转化率 | 试用期通过数 / 投递数 × 100% |
|
||||
|
||||
### 渠道 ROI 分析
|
||||
- 每渠道计算：成本 / 简历数、成本 / 入职数、成本 / 试用期通过数
|
||||
- 综合效率分 = 候选人质量分 × 0.4 + (1/单次入职成本) × 10000 × 0.3 + 试用期通过率 × 100 × 0.3
|
||||
|
||||
### 招聘周期分析
|
||||
- 平均招聘周期（天数）
|
||||
- 各环节耗时：简历筛选、面试流程、offer 审批、候选人决策
|
||||
|
||||
## Python 实现
|
||||
内置于 [[Recruitment Specialist Agent]] 的 `RecruitmentFunnelAnalyzer` 类，支持按职位、部门、周期筛选数据。
|
||||
|
||||
## 连接
|
||||
- [[Recruitment Specialist Agent]] — 内置分析工具
|
||||
- [[Structured Interview]] — 数据驱动决策支撑结构化面试标准
|
||||
40
wiki/concepts/Resource-Allocation.md
Normal file
40
wiki/concepts/Resource-Allocation.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "Resource Allocation"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Resource Allocation（资源分配）是在有限资源约束下，将人力、预算、技术和时间的组合进行最优配置的过程。区别于单一项目的资源管理，Portfolio 层面的资源分配需要在多个项目和不同项目阶段之间进行优先级权衡。
|
||||
|
||||
## Key Dimensions
|
||||
|
||||
- **Creative Resources**：设计师、创意人员、内容创作者
|
||||
- **Technical Resources**：工程师、开发人员、架构师
|
||||
- **Financial Resources**：预算分配、投资优先级
|
||||
- **Time Resources**：团队容量、时间盒规划
|
||||
- **Vendor Resources**：外部合作伙伴、自由职业者
|
||||
|
||||
## Portfolio-Level Principles
|
||||
|
||||
- **Prioritization Framework**：基于战略价值的项目分级（Tier 1/2/Innovation Pipeline）
|
||||
- **Capacity Planning**：团队容量与需求匹配，避免过载
|
||||
- **Trade-off Management**：短期交付与长期能力建设之间的权衡
|
||||
- **Dynamic Rebalancing**：根据 Portfolio Review 动态调整资源分配
|
||||
|
||||
## Relationship to Strategic Portfolio Management
|
||||
|
||||
Resource Allocation 是 [[Strategic-Portfolio-Management]] 的核心子功能之一。在 [[Project-Management-Studio-Producer]] 的框架中，Resource Allocation Strategy 是 Strategic Portfolio Plan 的核心组成部分，包含：
|
||||
- Team Capacity（当前和计划的团队组成）
|
||||
- Skill Development（培训和能力建设优先级）
|
||||
- External Partners（供应商和自由职业者战略关系）
|
||||
- Budget Distribution（跨组合层级的投资分配）
|
||||
|
||||
## Aliases
|
||||
- Resource Planning
|
||||
- Capacity Management
|
||||
- Budget Allocation
|
||||
- Talent Allocation
|
||||
73
wiki/concepts/SLS.md
Normal file
73
wiki/concepts/SLS.md
Normal file
@@ -0,0 +1,73 @@
|
||||
---
|
||||
title: "SLS"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Serviceability Limit State（正常使用极限状态）
|
||||
- 正常使用极限状态
|
||||
- 使用性极限状态
|
||||
- 挠度控制
|
||||
- Deflection Control
|
||||
|
||||
## Definition
|
||||
|
||||
正常使用极限状态（SLS, Serviceability Limit State）是结构设计中验证结构在正常使用时满足适用性要求的验算标准，关注的是结构的**使用功能、舒适度和耐久性**，而非安全性。SLS 验算确保建筑在使用荷载下不产生过大的变形、振动或裂缝，从而不影响正常使用。
|
||||
|
||||
## Core SLS Criteria
|
||||
|
||||
| 验算项目 | 典型限值 | 规范来源 |
|
||||
|---------|---------|---------|
|
||||
| 楼板挠度（活荷载） | L/360（住宅）/ L/480（办公） | ACI 318 Appendix B |
|
||||
| 梁挠度（活荷载） | L/360（吊顶）/ L/240（无吊顶） | AISC Steel Manual |
|
||||
| 悬臂挠度 | L/180 | ACI 318 |
|
||||
| 裂缝宽度（钢筋混凝土） | 0.3mm（室内）/ 0.4mm（室外） | EN 1992-1-1 |
|
||||
| 振动（人致振动） | 频率 ≥ 5Hz（办公）/ 加速度 < 0.5% g | AISC Design Guide 11 |
|
||||
| 裂缝宽度（梁） | 0.3mm（受拉钢筋保护层方向） | ACI 318-19 |
|
||||
|
||||
## SLS vs ULS
|
||||
|
||||
> **ULS 和 SLS 必须同时满足，方为合格设计。**
|
||||
> ULS 是安全底线（结构会不会塌），SLS 是使用品质（结构会不会晃/裂/变形过大影响功能）。
|
||||
|
||||
**控制关系的两种典型场景：**
|
||||
|
||||
1. **ULS 控制（Strength-Governed）**：高应力截面，承载力决定截面尺寸，挠度通常满足
|
||||
- 例子：高荷载短跨度钢梁
|
||||
|
||||
2. **SLS 控制（Deflection-Governed）**：低应力长跨度截面，挠度决定截面尺寸
|
||||
- 例子：活荷载下挠度超限的长跨度钢梁 → 需增大截面至 W24x55
|
||||
- 例子：预应力混凝土梁的反拱与长期挠度平衡
|
||||
|
||||
## SLS in Major Codes
|
||||
|
||||
### Eurocode EN 1990
|
||||
- **SLS 组合**（特征组合/频遇组合/准永久组合）：
|
||||
- 特征组合：Gk + Qk（不乘系数）
|
||||
- 频遇组合：Gk + ψ1Qk（ψ1 为频遇系数）
|
||||
- 准永久组合：Gk + ψ2Qk（ψ2 为准永久系数，ψ2 通常 < ψ1）
|
||||
- **挠度限值**：Annex NA.A（UK NA）或各国附录规定，通常 L/250
|
||||
|
||||
### ACI 318 (Appendix B)
|
||||
- **直接验算法**：计算总挠度 ΔT = ΔLP + ΔLT - Δi
|
||||
- ΔLP：恒荷载产生的即时挠度
|
||||
- ΔLT：长期荷载（持续荷载）产生的挠度
|
||||
- Δi：反拱（预应力或柱顶升引起的向上位移）
|
||||
- **容许挠度**：Table 24.2.2（ACI 318-19）按构件类型和吊顶条件规定限值
|
||||
|
||||
### AISC Steel Manual / AISC Design Guide 11
|
||||
- **挠度限值**：由使用者功能需求决定，无强制规范限值，但通常遵循 L/360 或 L/240
|
||||
- **振动验算**：高层楼板、人行天桥等人致振动，须验算固有频率和加速度响应
|
||||
|
||||
## Usage in Civil Engineer Agent
|
||||
|
||||
Civil Engineer Agent 在每个计算包中**必须同时检查 ULS 和 SLS**：
|
||||
1. 先验算 ULS（截面抗力是否足够）
|
||||
2. 再验算 SLS（挠度/裂缝/振动是否满足限值）
|
||||
3. 若 SLS 不满足 → **增大截面**（增加 Ix）或调整配筋
|
||||
4. **注明控制条件**：本次设计中由 SLS（挠度）控制，ULS 验算仅供参考
|
||||
|
||||
> **典型案例**：AISC 360 LRFD 钢梁 W21x44 — φMn ≥ Mu **通过 ULS**，但 δLL = 18.1mm > L/360 = 16.9mm **SLS 失败**，须增大至 W24x55。
|
||||
33
wiki/concepts/STARFramework.md
Normal file
33
wiki/concepts/STARFramework.md
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: "STAR Framework（行为面试法）"
|
||||
type: concept
|
||||
tags: [interview, behavioral-assessment, hiring]
|
||||
sources: [recruitment-specialist]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## 定义
|
||||
STAR Framework 是一种结构化行为面试方法，通过四个维度引导候选人描述其过去的工作经历：
|
||||
- **Situation（情境）**：描述事情发生的背景
|
||||
- **Task（任务）**：明确候选人需要完成的目标
|
||||
- **Action（行动）**：候选人具体采取了哪些行动
|
||||
- **Result（结果）**：最终取得了什么成果
|
||||
|
||||
## 在 [[Recruitment Specialist Agent]] 中的应用
|
||||
- 设计行为面试问题，基于 STAR 框架引导候选人提供具体案例
|
||||
- 针对不同能力维度准备追问提示
|
||||
- 关注候选人的具体行为，而非假设性回答
|
||||
- 使用结构化评分卡评估 STAR 回答的完整性和质量
|
||||
|
||||
## 使用场景
|
||||
适用于评估候选人的：
|
||||
- 团队协作能力
|
||||
- 问题解决能力
|
||||
- 领导力
|
||||
- 冲突管理能力
|
||||
- 客户导向意识
|
||||
|
||||
## 连接
|
||||
- [[Recruitment Specialist Agent]] — 该 Agent 的核心面试评估工具
|
||||
- [[Structured Interview]] — STAR 是结构化面试的重要组成部分
|
||||
- [[Structured Interview]] — 结构化面试结合 STAR 和评分卡确保评估一致性
|
||||
29
wiki/concepts/Spatial-Widgets.md
Normal file
29
wiki/concepts/Spatial-Widgets.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "Spatial Widgets"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: [visionos-spatial-engineer]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
visionOS 26 引入的小组件系统，可吸附于 3D 空间中的墙面、桌面等表面，并持久化放置在物理位置，无需应用处于前台运行即可展示。
|
||||
|
||||
## Core Characteristics
|
||||
- **Spatial Placement（空间放置）**：通过 SwiftUI API 定义 widget 在 3D 空间中的精确位置
|
||||
- **Surface Snapping（表面吸附）**：自动识别并吸附到墙面、桌面等物理表面
|
||||
- **Persistent Presence（持久化存在）**：Widget 保留在设定位置，用户返回时仍然可见
|
||||
- **Cross-App Usage（跨应用使用）**：作为系统级功能，所有应用可共享 widget 展示
|
||||
|
||||
## Implementation Technologies
|
||||
- **WidgetKit for visionOS**：Apple Widget 框架的 visionOS 扩展
|
||||
- **SwiftUI Volumetric Widgets**：支持 volumetric 展示模式的 widget 类型
|
||||
- **3D Positioning API**：定义 widget 在空间中的精确位置和朝向
|
||||
|
||||
## Related Concepts
|
||||
- [[Liquid Glass Design System]]：Widget 的视觉呈现采用 Liquid Glass 风格
|
||||
- [[Multi-Window Architecture]]：Widget 与主应用窗口的协同模式
|
||||
- [[Spatial Layouts]]：Widget 在 3D 空间中的布局管理
|
||||
|
||||
## Sources
|
||||
- [[visionos-spatial-engineer]] — visionOS Spatial Engineer Agent 角色定义
|
||||
45
wiki/concepts/Stakeholder-Alignment.md
Normal file
45
wiki/concepts/Stakeholder-Alignment.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: "Stakeholder Alignment"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Stakeholder Alignment（利益相关者对齐）是确保所有关键利益相关者（高管、团队、客户、供应商）对项目目标和方向达成共识的管理实践。在 [[Project-Management-Studio-Producer]] 的框架中，这是高管级战略沟通的核心能力。
|
||||
|
||||
## Stakeholder Categories
|
||||
|
||||
- **Executive Stakeholders**：C-suite、高管层——关注战略价值和商业影响
|
||||
- **Internal Stakeholders**：团队成员、部门——关注执行可行性和资源支持
|
||||
- **External Stakeholders**：客户、合作伙伴——关注交付价值和关系健康
|
||||
- **Regulatory Stakeholders**：合规、审计——关注法规遵从和治理
|
||||
|
||||
## Core Practices
|
||||
|
||||
- **Executive Communication**：面向高管层的战略叙事——"Our Q3 portfolio delivered 35% ROI while establishing market leadership"
|
||||
- **Expectation Setting**：明确界定范围、交付物和成功标准
|
||||
- **Strategic Investment Framing**：将项目投资包装为战略价值主张
|
||||
- **Board Presentation**：3年战略定位和竞争优势分析
|
||||
- **Feedback Loop**：建立双向沟通机制
|
||||
|
||||
## Communication Styles
|
||||
|
||||
| Context | Style | Example |
|
||||
|---------|-------|---------|
|
||||
| 战略规划 | 愿景驱动 | "This initiative positions us perfectly for the anticipated market shift" |
|
||||
| 高管汇报 | 价值量化 | "Creative excellence drove $5M revenue increase" |
|
||||
| 团队沟通 | 执行可行 | 技术细节和资源需求 |
|
||||
| 客户沟通 | 交付导向 | 交付物和价值实现 |
|
||||
|
||||
## Relationship to Strategic Portfolio Management
|
||||
|
||||
[[Project-Management-Studio-Producer]] 将 Stakeholder Alignment 作为核心职责，要求"Manage senior stakeholder relationships and executive-level communications"，是 Portfolio ROI 和按时交付之外的第三大成功要素。
|
||||
|
||||
## Aliases
|
||||
- Stakeholder Management
|
||||
- Executive Communication
|
||||
- Strategic Communication
|
||||
- Expectation Management
|
||||
35
wiki/concepts/Strategic-Portfolio-Management.md
Normal file
35
wiki/concepts/Strategic-Portfolio-Management.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: "Strategic Portfolio Management"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Strategic Portfolio Management（战略组合管理）是通过系统化方法管理多个相互关联的项目组合，以实现组织级商业目标的最大化。核心在于在组合层面进行资源优化配置、风险平衡和优先级排序，而非单个项目管理。
|
||||
|
||||
## Core Components
|
||||
|
||||
- **Portfolio Definition**：识别和定义组合的范围、边界和成员项目
|
||||
- **Strategic Alignment**：确保组合中所有项目与组织战略目标一致
|
||||
- **Resource Optimization**：跨项目分配有限资源，最大化整体 ROI
|
||||
- **Risk Balancing**：在创新项目与已验证项目之间平衡风险敞口
|
||||
- **Performance Monitoring**：组合层面的 KPI 追踪（Portfolio ROI、按时交付率）
|
||||
- **Governance**：定期 Portfolio Review 和战略调整机制
|
||||
|
||||
## Relationship to Single Project Management
|
||||
|
||||
| Dimension | Single Project Management | Strategic Portfolio Management |
|
||||
|-----------|-------------------------|-------------------------------|
|
||||
| Scope | 单个项目 | 多个相关项目的集合 |
|
||||
| Objective | 项目交付成功 | 组织战略目标实现 |
|
||||
| Time Horizon | 项目生命周期 | 持续、跨项目周期 |
|
||||
| Decision Maker | Project Manager | Executive/Portfolio Manager |
|
||||
| Success Metric | 铁三角（范围/时间/成本） | Portfolio ROI ≥ 25%，95% 按时交付 |
|
||||
|
||||
## Aliases
|
||||
- Portfolio Management
|
||||
- Project Portfolio Management
|
||||
- Strategic Portfolio Governance
|
||||
32
wiki/concepts/StructuredInterview.md
Normal file
32
wiki/concepts/StructuredInterview.md
Normal file
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: "Structured Interview（结构化面试）"
|
||||
type: concept
|
||||
tags: [interview, hiring, evaluation]
|
||||
sources: [recruitment-specialist]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## 定义
|
||||
结构化面试是一种标准化的面试方法，通过统一的评分标准、面试问题和评估维度，确保所有候选人接受同等条件的评估，提升面试的一致性和准确性。
|
||||
|
||||
## 在 [[Recruitment Specialist Agent]] 中的应用
|
||||
- 设计标准化面试评分卡，每个维度有明确的评分标准和行为锚定
|
||||
- 构建按岗位类型和职级分类的面试题库
|
||||
- 确保面试官一致性：培训面试官并校准评分标准
|
||||
- 与 [[STAR Framework]] 结合使用，提升评估深度
|
||||
|
||||
## 核心要素
|
||||
1. **标准化评分卡**：统一评估维度 + 行为锚定描述
|
||||
2. **题库**：按岗位类型、职级分类的预设问题
|
||||
3. **面试官培训**：确保评分标准一致性
|
||||
4. **校准机制**：定期回顾和校准面试评分
|
||||
|
||||
## 关键指标
|
||||
- 面试评估一致性（Inter-rater Reliability）
|
||||
- 预测效度（与入职后绩效的相关性）
|
||||
- 候选人体验评分
|
||||
|
||||
## 连接
|
||||
- [[Recruitment Specialist Agent]] — 结构化面试是该 Agent 招聘流程设计的核心
|
||||
- [[STAR Framework]] — STAR 是结构化面试的组成部分
|
||||
- [[Recruitment Specialist Agent]] — 内置面试题库和能力评估模型
|
||||
29
wiki/concepts/SwiftUI-Volumetric-APIs.md
Normal file
29
wiki/concepts/SwiftUI-Volumetric-APIs.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "SwiftUI Volumetric APIs"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: [visionos-spatial-engineer]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
visionOS 26 新增的 SwiftUI API 集，专门用于在 volumetric 空间场景中渲染和管理 3D 内容，实现声明式的空间界面开发。
|
||||
|
||||
## Core Capabilities
|
||||
- **3D Content Integration（3D 内容集成）**：将 RealityKit 实体无缝嵌入 SwiftUI 视图层级
|
||||
- **Volume Content（Volume 内容）**：支持在受限的 3D 空间（volume）内展示和管理内容
|
||||
- **Breakthrough UI（突破性 UI）**：允许 UI 元素突破传统窗口边界，融入 3D 场景
|
||||
- **Transient Content（临时内容）**：支持在 volume 内快速展示和消失的临时 UI 元素
|
||||
|
||||
## Key API Components
|
||||
- **@Observable Entities**：声明式状态管理，与 SwiftUI 视图自动同步
|
||||
- **Direct Gesture Handling**：在 3D 内容上直接处理手势输入
|
||||
- **ViewAttachmentComponent**：将 SwiftUI 视图附加到 RealityKit 实体上
|
||||
|
||||
## Related Concepts
|
||||
- [[RealityKit-SwiftUI Integration]]：SwiftUI Volumetric APIs 的底层集成机制
|
||||
- [[Spatial Layouts]]：3D 内容在空间中的定位和布局模式
|
||||
- [[Multi-Window Architecture]]：Volumetric 内容在多窗口场景下的管理
|
||||
|
||||
## Sources
|
||||
- [[visionos-spatial-engineer]] — visionOS Spatial Engineer Agent 角色定义
|
||||
63
wiki/concepts/ULS.md
Normal file
63
wiki/concepts/ULS.md
Normal file
@@ -0,0 +1,63 @@
|
||||
---
|
||||
title: "ULS"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Ultimate Limit State（极限状态设计）
|
||||
- 强度极限状态
|
||||
- 承载能力极限状态
|
||||
- Strength Limit State
|
||||
|
||||
## Definition
|
||||
|
||||
极限状态设计（ULS, Ultimate Limit State）是结构设计中验证结构承载能力的核心原则，要求结构在最大设计荷载组合下不发生承载能力失效。ULS 关注的是结构**是否会倒塌或发生不可接受的变形**，对应的是结构安全性的底线要求。
|
||||
|
||||
## Core Principle
|
||||
|
||||
> **ULS 核心公式**：`作用效应 ≤ 抗力`（Effect ≤ Resistance）
|
||||
|
||||
在 LRFD/SD 设计体系中：
|
||||
- **作用效应**（Demand）：通过荷载分项系数放大后的内力（弯矩 M、剪力 V、轴力 P）
|
||||
- **抗力**（Resistance）：通过抗力系数折减后的构件承载力（φMn、φVn、φPn）
|
||||
|
||||
## ULS vs SLS 对比
|
||||
|
||||
| 维度 | ULS（极限状态） | SLS（正常使用极限状态） |
|
||||
|------|----------------|----------------------|
|
||||
| 目标 | 防止倒塌和承载能力失效 | 防止使用功能受损 |
|
||||
| 设计方法 | LRFD/SD（分项系数法） | 容许挠度/裂缝宽度/振动频率 |
|
||||
| 关注点 | 安全性 | 适用性、耐久性 |
|
||||
| 验算条件 | φRn ≥ γi ΣQi | Δ ≤ Δ_limit |
|
||||
| 典型限值 | 截面承载力 | 挠度 L/360、裂缝 0.3mm |
|
||||
|
||||
**ULS 和 SLS 必须同时满足，方为合格设计。**
|
||||
|
||||
## ULS in Major Codes
|
||||
|
||||
### Eurocode (EN 1990)
|
||||
- **ULS 组合**（永久+可变+偶然）：γG Gk + γQ Qk + γQ ψ0 Qk,acc
|
||||
- **延性要求**：EN 1998 抗震设计 DCL/DCM/DCH 等级对 ULS 验算有不同的细部构造要求
|
||||
|
||||
### ACI 318 (Strength Design)
|
||||
- **ULS 组合**：U = 1.4D / U = 1.2D + 1.6L + 0.5(Lr 或 R)
|
||||
- **φ 系数**：φ = 0.90（抗弯）、φ = 0.75（抗剪）、φ = 0.65（轴压螺旋箍筋柱）
|
||||
|
||||
### AISC 360 (LRFD)
|
||||
- **ULS 组合**：U = 1.2D + 1.6L（主力组合）
|
||||
- **φ 系数**：φ = 0.90（抗弯构件）、φ = 0.75（抗剪）、φ = 0.90（轴拉）
|
||||
|
||||
## Usage in Civil Engineer Agent
|
||||
|
||||
Civil Engineer Agent 在每个计算包中**必须同时**检查 ULS 和 SLS：
|
||||
1. 首先进行 ULS 验算（截面是否满足 φRn ≥ Σγi Qi）
|
||||
2. 若 ULS 通过，进行 SLS 验算（挠度、裂缝、振动是否满足限值）
|
||||
3. 若 SLS 不满足，**增大截面或调整配筋**，直至两者同时满足
|
||||
4. 在计算包开头明确注明：所采用的分项系数和抗力系数（及其来源规范）
|
||||
|
||||
## Common Pitfall
|
||||
|
||||
> **ULS 通过 ≠ 设计完成**：结构可能在 ULS 验算中通过，但在 SLS（挠度）验算中失败。例如，AISC 360 LRFD 钢梁设计中，W21x44 可能满足抗弯 ULS，但 W24x55（更大截面）才是由挠度控制的选型。
|
||||
76
wiki/entities/ACI-318.md
Normal file
76
wiki/entities/ACI-318.md
Normal file
@@ -0,0 +1,76 @@
|
||||
---
|
||||
title: "ACI 318"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- ACI 318-19 / ACI 318-22（当前版本）
|
||||
- Building Code Requirements for Structural Concrete
|
||||
- 美国钢筋混凝土设计规范
|
||||
- American Concrete Institute 318
|
||||
|
||||
## Description
|
||||
|
||||
ACI 318 是美国钢筋混凝土结构设计的权威规范，全称 *Building Code Requirements for Structural Concrete*，由美国混凝土协会（ACI）发布，被 IBC 引用为混凝土结构设计的核准方法。ACI 318 采用与 AISC 360 相同的 LRFD（荷载抗力系数设计）和 SD（ Strength Design）方法体系。
|
||||
|
||||
## Core Content
|
||||
|
||||
- **Chapter 2** – General Requirements（一般要求）
|
||||
- **Chapter 3** – Loads（荷载）
|
||||
- **Chapter 4** – Structural Systems（结构体系）
|
||||
- **Chapter 5** – Load Effects（荷载效应）
|
||||
- **Chapter 6** – Load Effects Combinations（荷载组合）
|
||||
- **Chapter 7** – Member Design – One-Way Systems（单向构件设计）
|
||||
- **Chapter 9** – Member Design – Two-Way Action（双向构件设计）
|
||||
- **Chapter 10** – Shear and Torsion（抗剪与扭转）
|
||||
- **Chapter 11** – Development and Splices（钢筋锚固与搭接）
|
||||
- **Chapter 12** – Foundations（基础）
|
||||
- **Chapter 18** – Earthquake-Resistant Structures（抗震结构）
|
||||
|
||||
## Strength Design (SD) — LRFD 方法
|
||||
|
||||
ACI 318 采用 Strength Design（等同于 LRFD），核心公式：
|
||||
- **设计弯矩**：φMn ≥ Mu（φ = 0.90 抗弯，φ = 0.75 抗剪）
|
||||
- **抗压构件**：φPn ≥ Pu（φ = 0.65 螺旋箍筋柱，φ = 0.70 钢筋混凝土柱）
|
||||
- **荷载组合**（ACI 318-19 Eq. 5.3.1）：
|
||||
- U = 1.4D
|
||||
- U = 1.2D + 1.6L + 0.5(Lr 或 R)
|
||||
- U = 1.2D + 1.0E + L（地震组合）
|
||||
- U = 1.2D + 1.0W + L（风荷载组合）
|
||||
|
||||
## Seismic Provisions
|
||||
|
||||
ACI 318 Chapter 18 定义了特殊抗弯框架（Special Moment Frames, SMF）、中等抗弯框架（IMF）和普通抗弯框架（Ordinary Moment Frames）的细部构造要求：
|
||||
- **SMF**（ACI 318-19 §18.2–18.9）：梁柱节点区箍筋加密、强柱弱梁设计、钢筋延伸长度 ≥ 1.25Fy d（Flexural Tension）
|
||||
- **ACI 350**：Environmental Engineering Concrete Structures——供水厂、污水处理厂等耐久性要求更高的混凝土结构
|
||||
|
||||
## Jurisdiction
|
||||
|
||||
- **美国**：IBC 引用 ACI 318 作为混凝土结构设计标准，全美 50 个州 + 哥伦比亚特区采纳 IBC
|
||||
- **国际**：美国海外投资项目、海军设施、援建项目通常要求 ACI 318 合规；中东（UAE/沙特）部分项目同时要求 ACI 318 和本地规范
|
||||
|
||||
## Usage in Civil Engineer Agent
|
||||
|
||||
Civil Engineer Agent 使用 ACI 318 进行混凝土设计，计算包必须包含：
|
||||
1. ACI 318 版本年份（如 ACI 318-19）
|
||||
2. 混凝土 fc' 和钢筋 fy 强度值
|
||||
3. 抗弯设计（单筋/双筋/K 法/简化法）
|
||||
4. 抗剪设计（vcu + vsu，双向板冲切验算）
|
||||
5. 抗震细部检查（SMF/IMF 要求）
|
||||
6. 钢筋锚固与搭接长度验算
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[AISC-360]]：美国钢结构规范——ACI 318 的钢结构对应规范，同属 IBC 引用体系
|
||||
- [[Eurocode]] EN 1992：欧洲混凝土规范——与 ACI 318 并列，但 Eurocode 采用 K 法单筋设计（限制相对受压区高度），ACI 318 采用 φMn ≥ Mu 直接法，两者公式和参数体系不同，不可混用
|
||||
- [[ASCE-7]]：美国荷载规范——ACI 318 的荷载来源规范
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[LRFD]]（荷载抗力系数设计）：ACI 318 的主要设计方法
|
||||
- [[ULS]]（极限状态设计）：ACI 318 Strength Design 的核心哲学——以乘以系数的名义荷载与除以系数的名义抗力比较
|
||||
- [[SLS]]（正常使用极限状态）：ACI 318 在 Appendix B 中定义挠度控制要求（ACI 318-19 §20.3.1）
|
||||
- [[Basis-of-Design]]（设计依据报告）：须记录 ACI 318 版本、fc'/fy、特殊荷载组合及所有偏离默认值的参数
|
||||
74
wiki/entities/AISC-360.md
Normal file
74
wiki/entities/AISC-360.md
Normal file
@@ -0,0 +1,74 @@
|
||||
---
|
||||
title: "AISC 360"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- AISC 360-22（当前版本，AISC 360-16 为上一版）
|
||||
- American Institute of Steel Construction Specification
|
||||
- 美国钢结构设计规范
|
||||
- AISC Steel Construction Manual
|
||||
|
||||
## Description
|
||||
|
||||
AISC 360 是美国钢结构设计的权威规范，全称 *Specification for Structural Steel Buildings*，由美国钢结构协会（AISC）发布，被 IBC（国际建筑规范）引用为钢结构设计的核准方法。提供 LRFD（荷载抗力系数设计）和 ASD（容许应力设计）双轨制。
|
||||
|
||||
## Core Content
|
||||
|
||||
- **Chapter A**: General Provisions（总则）
|
||||
- **Chapter B**: Design Requirements（设计要求）
|
||||
- **Chapter C**: Design for Stability（稳定性设计）
|
||||
- **Chapter D**: Design of Members for Tension（轴拉构件）
|
||||
- **Chapter E**: Design of Members for Compression（轴压构件）
|
||||
- **Chapter F**: Design of Members for Flexure（受弯构件）
|
||||
- **Chapter G**: Design of Members for Shear（受剪构件）
|
||||
- **Chapter H**: Design of Members for Combined Forces（组合力构件）
|
||||
- **Chapter I**: Design of Composite Members（组合构件）
|
||||
- **Chapter J**: Design of Connections（连接设计）
|
||||
- **Chapter K**: Design for HSS and Box Members（HSS 和箱形截面）
|
||||
|
||||
## LRFD vs ASD
|
||||
|
||||
| | LRFD | ASD |
|
||||
|--|------|-----|
|
||||
| 设计方法 | 荷载抗力系数设计 | 容许应力设计 |
|
||||
| 荷载系数 | 1.2D + 1.6L（主力） | D + L（容许应力） |
|
||||
| 抗力系数 | φ（< 1.0，如 φ=0.90 抗弯） | Ω（如 Ω=1.67） |
|
||||
| 应用场景 | 新建结构首选 | 抗风/抗震校核、加固改造 |
|
||||
| 关系 | φRn ≥ ΣγiQi | Rn/Ω ≥ ΣQi |
|
||||
|
||||
## Key Provisions
|
||||
|
||||
- **截面分类**（Chapter B）：compact / noncompact / slender 分类决定屈曲验算方法
|
||||
- **直接分析法**（Chapter C）：AISC 360-10 引入，直接考虑几何和残余应力非线性，比有效长度法更精确
|
||||
- **抗震条款**：AISC 341（*Seismic Provisions for Structural Steel Buildings*）提供 SMF/IMF/SCBF/EBF/BRB 抗震体系详细要求
|
||||
- **连接设计**：AISC 358（*Prequalified Connections for Special Moment Frames*）提供预认证连接类型
|
||||
|
||||
## Jurisdiction
|
||||
|
||||
- **美国**：IBC（International Building Code）在全美 50 个州 + 哥伦比亚特区被采纳为建筑法规基准，IBC 引用 AISC 360 作为钢结构设计标准
|
||||
- **国际**：AISC 标准通过美国国际开发署（USAID）项目、全球石油/化工设施、美国跨国公司在海外的建设项目被广泛采用
|
||||
|
||||
## Usage in Civil Engineer Agent
|
||||
|
||||
Civil Engineer Agent 使用 AISC 360 LRFD 进行钢结构设计，计算包必须包含：
|
||||
1. 所引用的 AISC 360 版本年份
|
||||
2. 截面属性（W/HSS/Box 截面型号及牌号 A992/A572 Gr50）
|
||||
3. LRFD 荷载组合及对应的 φ 系数
|
||||
4. 截面 compactness 判定
|
||||
5. 抗弯/抗剪/稳定性验算全过程
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[Eurocode]] EN 1993：欧洲钢结构规范——与 AISC 360 并列，但 Eurocode 采用截面分类（Class 1-4）替代 compactness 概念，荷载分项系数体系不同，不可混用
|
||||
- [[ACI-318]]：美国混凝土规范——AISC 360 的混凝土对应规范，同属美国 IBC 引用体系
|
||||
- [[ASCE-7]]：美国荷载规范——AISC 360 的荷载来源规范，风荷载、地震荷载、重力荷载均引用 ASCE 7
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[LRFD]]（荷载抗力系数设计）：AISC 360 的主要设计方法
|
||||
- [[ULS]]（极限状态设计）：AISC 360 LRFD 的设计哲学基础
|
||||
- [[Basis-of-Design]]（设计依据报告）：AISC 360 项目须记录所选用的设计方法（LRFD/ASD）
|
||||
81
wiki/entities/ASCE-7.md
Normal file
81
wiki/entities/ASCE-7.md
Normal file
@@ -0,0 +1,81 @@
|
||||
---
|
||||
title: "ASCE 7"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- ASCE 7-22（当前版本，ASCE 7-16 为上一版）
|
||||
- Minimum Design Loads and Associated Criteria for Buildings and Other Structures
|
||||
- 美国建筑结构最小设计荷载规范
|
||||
- ASCE Standard 7
|
||||
|
||||
## Description
|
||||
|
||||
ASCE 7 是美国建筑及其他结构最小设计荷载规范的权威标准，全称 *Minimum Design Loads and Associated Criteria for Buildings and Other Structures*，由美国土木工程师协会（ASCE）发布，被 IBC（International Building Code）引用为所有建筑结构荷载计算的核准方法。涵盖重力荷载、风荷载、地震荷载、雪荷载、雨荷载、温度作用、冲击荷载等。
|
||||
|
||||
## Core Content — Chapters
|
||||
|
||||
| Chapter | 主题 | 核心内容 |
|
||||
|---------|------|---------|
|
||||
| Ch 1 | Scope and General Requirements | 规范范围、荷载分类 |
|
||||
| Ch 2 | Load Combinations | 基于 LRFD 和 ASD 的荷载组合 |
|
||||
| Ch 3 | Dead Loads and Collateral Loads | 恒荷载、固定设备荷载 |
|
||||
| Ch 4 | Live Loads | 楼面活荷载、屋顶活荷载 |
|
||||
| Ch 5 | Flood Loads | 洪水荷载 |
|
||||
| Ch 6 | Reserved | 保留章节 |
|
||||
| Ch 7 | Tsunami Loads | 海啸荷载 |
|
||||
| Ch 8 | Wind Loads | 风荷载——速度压力公式、围护结构/主体结构 |
|
||||
| Ch 9 | Seismic Loads | 地震荷载——反应谱、侧向力法、等效侧向力 |
|
||||
| Ch 10 | Snow Loads | 雪荷载——地面雪荷载、屋面雪荷载 |
|
||||
| Ch 11 | Rain Loads | 雨荷载 |
|
||||
| Ch 12 | Load Combinations for Strength Design (LRFD) | LRFD 荷载组合 |
|
||||
| Ch 13 | Load Combinations for Allowable Stress Design | ASD 荷载组合 |
|
||||
| Ch 26 | Reliability Provisions | 可靠性条款 |
|
||||
|
||||
## Key Methods
|
||||
|
||||
### Wind Load (Chapter 8)
|
||||
- **速度压力公式**：q = 0.613 Kz Kzt Kd V² I（psf，US 单位）
|
||||
- **主建筑系统（Main Wind Force Resisting System）**：建筑整体风荷载
|
||||
- **围护结构（Components & Cladding）**：屋面、墙面、窗户的风荷载
|
||||
- **风压高度变化系数 Kz**：根据地面粗糙度和高度确定
|
||||
- **地形系数 Kzt**：山峰、悬崖等陡峭地形的放大系数
|
||||
- **方向系数 Kd**：风向对不同建筑形状的影响
|
||||
|
||||
### Seismic Load (Chapter 9)
|
||||
- **反应谱分析**：SDS（短周期加速度）、SD1（一秒周期加速度）——从 USGS 地震危害数据库获取
|
||||
- **等效侧向力法**（ELF）：V = Cs W，Cs = SDS / (R/I)
|
||||
- **建筑重要性系数 I**：Occupancy Category I/II/III/IV
|
||||
- **响应修正系数 R**：结构体系延性折减（SMF R=8, SCBF R=6, OMF R=3.5）
|
||||
- **高度限制**：超过 160 ft（~48.8 m）的建筑需进行动态分析
|
||||
|
||||
## Jurisdiction
|
||||
|
||||
- **美国**：IBC 引用 ASCE 7，全美 50 个州 + 哥伦比亚特区采纳 IBC 作为建筑法规基准
|
||||
- **国际**：美国海外投资项目采用 ASCE 7 作为荷载计算标准；部分加勒比海/太平洋岛国（受美国援助影响）也采用 ASCE 7
|
||||
|
||||
## Usage in Civil Engineer Agent
|
||||
|
||||
Civil Engineer Agent 使用 ASCE 7 进行荷载计算，计算包必须包含：
|
||||
1. ASCE 7 版本年份
|
||||
2. 建筑使用类别（Occupancy Category）和重要性系数 I
|
||||
3. 地面粗糙度类别（Exposure B/C/D）
|
||||
4. 基本风速 V（mph）和风向系数 Kd
|
||||
5. 地震参数 SDS、SD1（来自 USGS EHP 或项目地震报告）
|
||||
6. 响应修正系数 R 和结构体系类型
|
||||
7. 所有荷载组合及其对应的抗力系数
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[AISC-360]]：使用 ASCE 7 的风荷载和地震荷载作为钢结构的输入
|
||||
- [[ACI-318]]：使用 ASCE 7 的荷载组合作为混凝土结构的输入
|
||||
- [[Eurocode]] EN 1991：欧洲作用（荷载）规范——与 ASCE 7 并列，但风荷载谱（孟加拉风谱 vs ASCE 7 对数风谱）、地震反应谱（中国标准 GB 50011 vs ASCE 7）完全不同
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[ULS]]（极限状态设计）：ASCE 7 荷载组合服务于 LRFD/SD 极限状态设计
|
||||
- [[LRFD]]（荷载抗力系数设计）：ASCE 7 Chapter 12 定义 LRFD 荷载组合，AISC 360 和 ACI 318 均引用
|
||||
- [[Basis-of-Design]]（设计依据报告）：须记录 ASCE 7 版本、建筑使用类别、基本风速、地震参数、地面粗糙度类别等所有输入
|
||||
31
wiki/entities/BossZhipin.md
Normal file
31
wiki/entities/BossZhipin.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: "Boss Zhipin（BOSS直聘）"
|
||||
type: entity
|
||||
tags: [hiring-platform, china]
|
||||
sources: [recruitment-specialist]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- BOSS直聘
|
||||
- Boss Zhipin
|
||||
|
||||
## 定义
|
||||
中国领先的直聊式招聘平台，以"直聊"为核心差异化特性，连接招聘方与求职者，实现即时沟通。简历获取成本约为猎聘（Liepin）的三分之一，适合大量招聘初级岗位。
|
||||
|
||||
## 在 [[Recruitment Specialist Agent]] 中的定位
|
||||
- 优化公司页面和职位卡片设计
|
||||
- 掌握"直聊"互动技巧，提升候选人响应率
|
||||
- 利用人才推荐和定向邀请功能
|
||||
- 分析职位曝光量与简历转化率
|
||||
- ROI 分析：简历成本低，适合初级岗位批量招聘
|
||||
|
||||
## 核心指标
|
||||
- 简历成本：约为 Liepin 的 1/3
|
||||
- 适用岗位层级：初级至中级
|
||||
- 核心优势：直聊即时性、简历数量大、成本可控
|
||||
|
||||
## 连接
|
||||
- [[Recruitment Specialist Agent]] — 使用该平台进行初级岗位招聘
|
||||
- [[Liepin]] — 对比：Liepin 适合中高端岗位，简历质量更高但成本更高
|
||||
- [[Lagou]] — 另一互联网招聘平台，专注科技岗位
|
||||
63
wiki/entities/Eurocode.md
Normal file
63
wiki/entities/Eurocode.md
Normal file
@@ -0,0 +1,63 @@
|
||||
---
|
||||
title: "Eurocode"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- EN 1990–1999（欧洲规范编号体系）
|
||||
- EC（Eurocode 缩写）
|
||||
- 欧盟结构设计标准
|
||||
- European Structural Design Standards
|
||||
|
||||
## Description
|
||||
|
||||
Eurocode 是欧洲结构工程设计标准体系，涵盖 EN 1990 至 EN 1999 九大领域，是全球最全面的结构设计规范框架之一，被欧盟成员国及全球多国（中东、亚洲、非洲）广泛采用或参考。
|
||||
|
||||
## Core Standards
|
||||
|
||||
| 编号 | 主题 | 核心内容 |
|
||||
|------|------|---------|
|
||||
| EN 1990 | 结构设计基础 | 荷载组合、可靠度分类、极限状态原则 |
|
||||
| EN 1991 | 结构上的作用 | 恒荷载、活荷载、风荷载、雪荷载、温度作用、偶然作用 |
|
||||
| EN 1992 | 混凝土结构 | 钢筋混凝土与预应力混凝土设计 |
|
||||
| EN 1993 | 钢结构 | 钢构件与连接设计 |
|
||||
| EN 1994 | 钢-混凝土组合结构 | 组合梁、组合柱设计 |
|
||||
| EN 1995 | 木结构 | 木结构设计 |
|
||||
| EN 1996 | 砌体结构 | 砌体结构设计 |
|
||||
| EN 1997 | 岩土设计 | 浅基础、深基础、挡土结构、边坡稳定 |
|
||||
| EN 1998 | 抗震设计 | 地震作用下的结构设计，含延性等级 DCL/DCM/DCH |
|
||||
|
||||
## Key Characteristics
|
||||
|
||||
- **部分系数法**（Partial Factor Method）：EN 1990 定义了三套设计方法（DA1/DA2/DA3），对作用和抗力分别应用分项系数
|
||||
- **National Annex（NDPs）**：各成员国通过 National Annex 修订国家确定参数（NDPs），可显著改变设计结果——同一结构在不同国家的验算结果可能不同
|
||||
- **延性等级**：EN 1998 抗震设计分为 DCL（低延性）、DCM（中延性）、DCH（高延性）三级，对应不同的细部构造要求
|
||||
|
||||
## Jurisdiction
|
||||
|
||||
- **欧洲**：欧盟 27 国 + 英国（UK National Annex）、瑞士、土耳其
|
||||
- **国际**：中东（阿联酋、沙特等在 Eurocode 基础上增加本地附录）、亚洲（部分国家将 Eurocode 作为参考标准）、全球基础设施项目（欧洲银行融资项目通常要求 Eurocode 合规）
|
||||
|
||||
## Usage in Civil Engineer Agent
|
||||
|
||||
Civil Engineer Agent 使用 Eurocode 作为全球设计标准之一，必须在计算包开头注明：
|
||||
1. 适用的 EN 标准编号和年份版本
|
||||
2. 所采用的 National Annex（如 DE-NA、UK-NA）
|
||||
3. 选用的 NDPs（与 EN 默认值的偏差）
|
||||
4. 设计方法（DA1/DA2/DA3）
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[AISC-360]]：美国钢结构规范——与 Eurocode EN 1993 并列，同为核心钢结构设计标准，但荷载分项系数和截面分类方法不同，不可混用
|
||||
- [[ACI-318]]：美国混凝土规范——与 Eurocode EN 1992 并列，LRFD 方法与 Eurocode 部分系数法思路相近但系数体系不同
|
||||
- [[ASCE-7]]：美国荷载规范——与 Eurocode EN 1991 并列，同为荷载标准，但风荷载谱、地震反应谱划分、荷载组合公式均有差异
|
||||
- [[EN-1997]]：岩土设计——Eurocode 岩土部分，是独立的岩土工程设计框架
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[ULS]]（极限状态设计）：Eurocode 核心设计哲学，同时验证 ULS 和 SLS
|
||||
- [[National-Annex]]（国家附录）：Eurocode 各成员国的本地化修订机制，是 Eurocode 体系内规范冲突的主要来源
|
||||
- [[Basis-of-Design]]（设计依据报告）：记录所有规范选择和假设的文件
|
||||
49
wiki/entities/Gitmoji.md
Normal file
49
wiki/entities/Gitmoji.md
Normal file
@@ -0,0 +1,49 @@
|
||||
---
|
||||
title: "Gitmoji"
|
||||
type: entity
|
||||
tags: ["tool", "git", "commit-standards"]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- gitmoji
|
||||
- Gitmoji
|
||||
|
||||
## Type
|
||||
Commit Standard Tool
|
||||
|
||||
## Description
|
||||
|
||||
Gitmoji 是一个标准化 Emoji 提交规范工具，通过在 Git commit message 前缀标准化的 Emoji，使开发团队能够在 git log 中通过视觉标签快速识别变更类型和意图。
|
||||
|
||||
## Official References
|
||||
|
||||
- **Primary**: [gitmoji.dev](https://gitmoji.dev/) — 当前 emoji 目录和标准含义
|
||||
- **Source of truth**: [github.com/carloscuesta/gitmoji](https://github.com/carloscuesta/gitmoji) — 上游项目和最佳实践模型
|
||||
|
||||
## Key Gitmojis
|
||||
|
||||
| Emoji | 含义 | Gitmoji 官方定义 |
|
||||
|-------|------|----------------|
|
||||
| ✨ | 新功能 | Introducing new features |
|
||||
| 🐛 | 缺陷修复 | Fixing a bug |
|
||||
| ♻️ | 重构 | Refactoring code |
|
||||
| 📚 | 文档 | Updating docs |
|
||||
| 🧪 | 测试 | Adding tests |
|
||||
| 💄 | 样式 | Updating UI/style |
|
||||
| 🔧 | 配置 | Changing config files |
|
||||
| 📦 | 依赖 | Updating packages |
|
||||
| 🚀 | 部署 | Deploying stuff |
|
||||
|
||||
## Usage in The Agency
|
||||
|
||||
[[Jira Workflow Steward]] Agent 使用 Gitmoji 作为 [[Gitmoji-Commit]] 规范的视觉层：
|
||||
- 格式：`<Gitmoji> JIRA-ID: short description`
|
||||
- 选择依据：变更的实际类型，而非个人偏好
|
||||
- 新增新 agent（catalog 功能）→ 优先 `✨`（因为 Gitmoji 定义为新功能）
|
||||
- 仅更新现有文档 → 使用 `📚`
|
||||
|
||||
Gitmoji 同时用于 commit-msg hook 的正则表达式验证，不符合规范的提交会被拒绝。
|
||||
|
||||
## Sources
|
||||
- [[project-management-jira-workflow-steward]]（主要来源）
|
||||
56
wiki/entities/Jira-Workflow-Steward.md
Normal file
56
wiki/entities/Jira-Workflow-Steward.md
Normal file
@@ -0,0 +1,56 @@
|
||||
---
|
||||
title: "Jira Workflow Steward"
|
||||
type: entity
|
||||
tags: ["agent-personality", "project-management", "delivery-traceability", "the-agency"]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Jira Workflow Steward
|
||||
- Jira Workflow Steward Agent
|
||||
|
||||
## Type
|
||||
Agent Personality（The Agency — Project Management 部门）
|
||||
|
||||
## Role
|
||||
|
||||
**Jira Workflow Steward** 是 The Agency 项目管理部门的交付纪律守护者（delivery disciplinarian），专职通过 Jira-Git 全链路绑定，确保每一次代码变更都能从 Jira 任务追踪到分支、提交、PR 直至关线发布。
|
||||
|
||||
核心定位：**拒绝匿名代码**——如果某项变更无法从 Jira 追踪到分支、提交、PR 直至发布，则视为工作流不完整。
|
||||
|
||||
## Identity
|
||||
|
||||
- **Role**: Delivery traceability lead, Git workflow governor, Jira hygiene specialist
|
||||
- **Personality**: Exacting, low-drama, audit-minded, developer-pragmatic
|
||||
- **Memory**: 记得哪些分支规则在真实团队中真正有效、哪些 commit 结构能减少 review 摩擦、哪些工作流政策在交付压力下会崩溃
|
||||
|
||||
## Core Responsibilities
|
||||
|
||||
1. **Jira Gate**：强制要求所有 Git 工作流输出携带有效 Jira Task ID
|
||||
2. **Branch Strategy**：规范 feature/bugfix/hotfix/release 分支类型和命名
|
||||
3. **Commit Hygiene**：通过 Gitmoji 规范和 Jira 绑定保持提交历史可读
|
||||
4. **PR Governance**：通过 PR 模板、安全审查要求保护合并质量
|
||||
5. **Delivery Auditable**：使从需求到发布代码的路径可在 10 分钟内重建
|
||||
|
||||
## Workflow
|
||||
|
||||
1. 确认 Jira 锚点（Jira Task ID 存在）
|
||||
2. 分类变更类型（Feature/Bugfix/Hotfix/Refactor/Docs/Tests/Config/Dependencies）
|
||||
3. 构建交付骨架（branch name + planned commits + PR template）
|
||||
4. 安全和范围审查（无 secrets、scope creep 检查）
|
||||
5. 关闭可追溯性循环（PR 链接 ticket + branch + commits + test evidence + risk areas）
|
||||
|
||||
## Success Metrics
|
||||
|
||||
- 100% 的可合并分支映射到有效 Jira 任务
|
||||
- Commit 命名合规率 ≥ 98%
|
||||
- Reviewer 在 5 秒内通过 commit subject 识别变更类型和 ticket 上下文
|
||||
- 从 Jira + Git 历史重建发布说明 < 10 分钟
|
||||
|
||||
## Related Agents
|
||||
|
||||
- [[Project-Management-Project-Shepherd]]：上游协调者，提供 Jira 任务输入
|
||||
- [[Project-Management-Studio-Operations]]：运营流程协同，Jira Workflow Steward 负责技术交付链路
|
||||
|
||||
## Sources
|
||||
- [[project-management-jira-workflow-steward]]（主要来源）
|
||||
54
wiki/entities/Project-Management-Experiment-Tracker.md
Normal file
54
wiki/entities/Project-Management-Experiment-Tracker.md
Normal file
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: "Project-Management-Experiment-Tracker"
|
||||
type: entity
|
||||
tags: ["agent", "project-management", "experimentation"]
|
||||
sources: ["project-management-experiment-tracker"]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Overview
|
||||
Experiment Tracker（实验追踪专家）是 The Agency 项目管理部门的 AI Agent，专注于实验设计、执行追踪与数据驱动决策的专家级项目经理。通过严格的统计方法论管理 A/B 测试、功能实验和假设验证，确保 95% 置信度的数据驱动决策可靠性。
|
||||
|
||||
## Role
|
||||
- **Type**: AI Agent / Project Management
|
||||
- **Department**: The Agency — Project Management
|
||||
- **Color**: Purple
|
||||
- **Emoji**: 🧪
|
||||
- **Vibe**: Designs experiments, tracks results, and lets the data decide.
|
||||
|
||||
## Core Responsibilities
|
||||
- 设计统计有效的 A/B 测试和多变量实验（默认 95% 置信度）
|
||||
- 管理实验 Portfolio 组合（每季度 15+ 实验，70% 成功率）
|
||||
- 执行统计功效分析确定所需样本量
|
||||
- 实施渐进放量与安全监控（含 Rollback 机制）
|
||||
- 80% 成功实验实现落地并驱动业务影响
|
||||
|
||||
## Advanced Capabilities
|
||||
- **Multi-armed Bandits**：动态流量分配，实时优化实验资源
|
||||
- **Bayesian Analysis**：贝叶斯分析方法，支持连续学习与实时决策
|
||||
- **Causal Inference**：因果推断技术，理解实验的真正效果
|
||||
- **ML Model A/B Testing**：机器学习模型 A/B 测试与预测建模
|
||||
- **Meta-analysis**：跨多实验的元分析能力
|
||||
|
||||
## Deliverables
|
||||
1. **实验设计文档**：假设陈述、成功指标、变体设计、风险评估、实施计划
|
||||
2. **实验结果报告**：统计结果、置信区间、业务影响、决策建议
|
||||
3. **Portfolio 分析**：跨实验资源优化、优先级排序、长期路线图
|
||||
|
||||
## Success Metrics
|
||||
| Metric | Target |
|
||||
|--------|--------|
|
||||
| 实验达统计显著性 | 95% |
|
||||
| 每季度实验数量 | 15+ |
|
||||
| 实验成功率 | 70% |
|
||||
| 成功实验落地率 | 80% |
|
||||
| 生产事故数 | 0 |
|
||||
| 用户体验降级 | 0 |
|
||||
|
||||
## Connections
|
||||
- [[Project-Management-Studio-Producer]] — 受益于实验数据的 Portfolio 优化
|
||||
- [[Project-Management-Studio-Operations]] — 潜在张力：实验节奏 vs 内容制作节奏
|
||||
- [[Project-Management-Jira-Workflow-Steward]] — 实验结果转化为 Jira 产品改进任务
|
||||
- [[Project-Management-Project-Shepherd]] — 利用实验数据支持项目看护
|
||||
- [[LaunchDarkly]] — Feature Flag 平台，支撑渐进放量与 A/B 测试
|
||||
- [[UX-Researcher]] — 共同使用 A/B 测试框架验证设计决策
|
||||
44
wiki/entities/Studio-Producer.md
Normal file
44
wiki/entities/Studio-Producer.md
Normal file
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: "Studio Producer"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- None known
|
||||
|
||||
## Description
|
||||
|
||||
Studio Producer 是 The Agency 项目管理部门中最高战略层级的 Agent，专注于高管级别的创意与商业目标对齐的组合管理。核心职责：战略组合规划、Portfolio ROI 管理（≥ 25%）、95% 按时交付、高管级利益相关者沟通。
|
||||
|
||||
## Role Characteristics
|
||||
|
||||
- **Type**: AI Agent (Personality)
|
||||
- **Department**: The Agency — Project Management
|
||||
- **Level**: Executive/Strategic
|
||||
- **Color**: Gold
|
||||
- **Emoji**: 🎬
|
||||
- **Vibe**: Aligns creative vision with business objectives across complex initiatives
|
||||
|
||||
## Core Deliverables
|
||||
|
||||
- Strategic Portfolio Plan（战略组合计划）—— Tier 1/2/Innovation Pipeline 三级分级
|
||||
- Strategic Portfolio Review（战略组合复盘）—— 季度/周期复盘模板
|
||||
- Executive Communication—— Board 级别战略汇报
|
||||
|
||||
## Success Metrics
|
||||
|
||||
- Portfolio ROI ≥ 25%
|
||||
- 95% on-time delivery
|
||||
- Client satisfaction 4.8/5
|
||||
- Market top 3 positioning
|
||||
- Team retention above industry benchmarks
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[Project-Management-Studio-Operations]]：执行搭档
|
||||
- [[Project-Manager-Senior]]：执行层项目经理
|
||||
- [[Project-Management-Project-Shepherd]]：项目看护角色
|
||||
- [[Project-Management-Experiment-Tracker]]：实验跟踪角色
|
||||
30
wiki/entities/XR-Cockpit-Interaction-Specialist.md
Normal file
30
wiki/entities/XR-Cockpit-Interaction-Specialist.md
Normal file
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: "XR Cockpit Interaction Specialist"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: [xr-cockpit-interaction-specialist, xr-interface-architect, visionos-spatial-engineer]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- XR Cockpit Interaction Specialist
|
||||
- XR Cockpit Interaction Specialist Agent
|
||||
- XR-Cockpit-Interaction-Specialist
|
||||
|
||||
## Role
|
||||
The Agency — Spatial Computing 部门座舱交互专家 Agent，专注于设计和实现固定视角、高存在感的座舱交互环境。
|
||||
|
||||
## Description
|
||||
XR Cockpit Interaction Specialist 智能体核心设计原则：约束驱动控制机制（constraint-driven control mechanics）消除自由漂浮运动，通过 3D meshes 和输入约束将控制物理化；座舱人体工学对齐自然的眼-手-头协调流动；多模态交互集成（手势/语音/注视/物理道具）；固定视角设计降低运动病阈值。典型应用场景：模拟指挥中心、航天器座舱、XR 载具界面、训练模拟器。
|
||||
|
||||
## Related Entities
|
||||
- [[XR-Interface-Architect]]：同部门界面架构专家
|
||||
- [[XR-Immersive-Developer]]：同部门 WebXR 开发专家
|
||||
- [[macOS-Spatial-Metal-Engineer]]：同部门 Apple 平台渲染专家
|
||||
- [[visionos-spatial-engineer]]：同部门 visionOS 原生开发专家
|
||||
- [[Terminal-Integration-Specialist]]：同部门终端集成专家
|
||||
|
||||
## Sources
|
||||
- [[xr-cockpit-interaction-specialist]] — Agent 角色定义源文档
|
||||
- [[xr-interface-architect]] — 相关参考
|
||||
- [[visionos-spatial-engineer]] — 相关参考
|
||||
30
wiki/entities/XR-Immersive-Developer.md
Normal file
30
wiki/entities/XR-Immersive-Developer.md
Normal file
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: "XR Immersive Developer"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: [xr-immersive-developer, xr-interface-architect, xr-cockpit-interaction-specialist, visionos-spatial-engineer]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- XR Immersive Developer
|
||||
- XR-Immersive-Developer
|
||||
|
||||
## Role
|
||||
The Agency — Spatial Computing 部门 WebXR 前端工程师 Agent，专注于在浏览器环境下构建跨平台高性能 AR/VR/XR 体验。
|
||||
|
||||
## Description
|
||||
XR Immersive Developer 智能体核心栈为 A-Frame / Three.js / Babylon.js，核心能力包括 WebXR Device API 全套沉浸式支持（hand tracking / pinch / gaze / controller input）、raycasting / hit testing / 实时物理交互、LOD 系统 / occlusion culling / shader tuning 性能优化、跨设备兼容层（Meta Quest / Vision Pro / HoloLens / mobile AR）。典型交付物：VR 训练模拟器、AR 可视化界面、空间界面。
|
||||
|
||||
## Related Entities
|
||||
- [[XR-Cockpit-Interaction-Specialist]]：同部门座舱交互专家
|
||||
- [[XR-Interface-Architect]]：同部门界面架构专家
|
||||
- [[macOS-Spatial-Metal-Engineer]]：同部门 Apple 平台渲染专家
|
||||
- [[visionos-spatial-engineer]]：同部门 visionOS 原生开发专家
|
||||
- [[Terminal-Integration-Specialist]]：同部门终端集成专家
|
||||
|
||||
## Sources
|
||||
- [[xr-immersive-developer]] — Agent 角色定义源文档
|
||||
- [[xr-interface-architect]] — 相关参考
|
||||
- [[xr-cockpit-interaction-specialist]] — 相关参考
|
||||
- [[visionos-spatial-engineer]] — 相关参考
|
||||
29
wiki/entities/XR-Interface-Architect.md
Normal file
29
wiki/entities/XR-Interface-Architect.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "XR Interface Architect"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: [xr-interface-architect, xr-cockpit-interaction-specialist, visionos-spatial-engineer]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- XR Interface Architect
|
||||
- XR-Interface-Architect
|
||||
|
||||
## Role
|
||||
The Agency — Spatial Computing 部门 UX/UI 设计专家 Agent，专注于为 AR/VR/XR 沉浸式环境创建直觉化、舒适且可发现的界面。
|
||||
|
||||
## Description
|
||||
XR Interface Architect 智能体通过 HUD / 浮动菜单 / 交互区域设计，支持直接触摸、注视+捏合、控制器和手势四种输入模型，基于人体工程学约束进行 UI 放置以减少晕动症，构建座舱/仪表盘/可穿戴界面布局模板，并运行可用性验证实验。
|
||||
|
||||
## Related Entities
|
||||
- [[XR-Immersive-Developer]]：同部门 WebXR 开发专家
|
||||
- [[XR-Cockpit-Interaction-Specialist]]：同部门座舱交互专家
|
||||
- [[macOS-Spatial-Metal-Engineer]]：同部门 Apple 平台渲染专家
|
||||
- [[visionos-spatial-engineer]]：同部门 visionOS 原生开发专家
|
||||
- [[Terminal-Integration-Specialist]]：同部门终端集成专家
|
||||
|
||||
## Sources
|
||||
- [[xr-interface-architect]] — Agent 角色定义源文档
|
||||
- [[xr-cockpit-interaction-specialist]] — 相关参考
|
||||
- [[visionos-spatial-engineer]] — 相关参考
|
||||
29
wiki/entities/macOS-Spatial-Metal-Engineer.md
Normal file
29
wiki/entities/macOS-Spatial-Metal-Engineer.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "macOS Spatial Metal Engineer"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: [macos-spatial-metal-engineer, xr-cockpit-interaction-specialist, visionos-spatial-engineer]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- macOS Spatial/Metal Engineer
|
||||
- macOS Spatial Metal Engineer
|
||||
- macOS-Spatial-Metal-Engineer
|
||||
|
||||
## Role
|
||||
The Agency — Spatial Computing 部门 Apple 平台 Metal 渲染与空间计算工程师 Agent，专注于 Swift + Metal 的高性能 3D 渲染系统和 visionOS 空间计算体验。
|
||||
|
||||
## Description
|
||||
macOS Spatial/Metal Engineer 智能体核心能力包括：实例化 Metal 渲染（Instanced Rendering）驱动 10k-100k 节点图数据，目标 90fps 立体渲染；通过 RemoteImmersiveSpace 和 LayerRenderer（stereo 模式、RGBA16Float + Depth32Float）实现 macOS 到 Vision Pro 的帧流传输；Metal Compute Shader 执行 GPU 并行力导向图物理模拟。性能约束：GPU 利用率 < 80%、每帧 < 100 draw calls、内存 < 1GB。
|
||||
|
||||
## Related Entities
|
||||
- [[XR-Interface-Architect]]：同部门界面架构专家
|
||||
- [[XR-Immersive-Developer]]：同部门 WebXR 开发专家
|
||||
- [[XR-Cockpit-Interaction-Specialist]]：同部门座舱交互专家
|
||||
- [[visionos-spatial-engineer]]：同部门 visionOS 原生开发专家
|
||||
- [[Terminal-Integration-Specialist]]：同部门终端集成专家
|
||||
|
||||
## Sources
|
||||
- [[macos-spatial-metal-engineer]] — Agent 角色定义源文档
|
||||
- [[visionos-spatial-engineer]] — 相关参考
|
||||
@@ -4,6 +4,15 @@
|
||||
- [Overview](overview.md) — living synthesis
|
||||
|
||||
## Sources
|
||||
- [2026-04-24] [Recruitment Specialist Agent](sources/recruitment-specialist.md)
|
||||
- [2026-04-24] [Specialized Civil Engineer Agent](sources/specialized-civil-engineer.md)
|
||||
- [2026-04-24] [Experiment Tracker Agent Personality](sources/project-management-experiment-tracker.md)
|
||||
- [2026-04-24] [Studio Operations Agent Personality](sources/project-management-studio-operations.md)
|
||||
- [2026-04-24] [Senior Project Manager Agent Personality](sources/project-manager-senior.md)
|
||||
- [2026-04-24] [Jira Workflow Steward Agent Personality](sources/project-management-jira-workflow-steward.md)
|
||||
- [2026-04-24] [Project Shepherd Agent Personality](sources/project-management-project-shepherd.md)
|
||||
- [2026-04-24] [Studio Producer Agent Personality](sources/project-management-studio-producer.md)
|
||||
- [2026-04-24] [visionOS Spatial Engineer](sources/visionos-spatial-engineer.md)
|
||||
- [2026-04-24] [XR Interface Architect Agent Personality](sources/xr-interface-architect.md)
|
||||
- [2026-04-24] [macOS Spatial/Metal Engineer Agent Personality](sources/macos-spatial-metal-engineer.md)
|
||||
- [2026-04-24] [Terminal Integration Specialist](sources/terminal-integration-specialist.md)
|
||||
@@ -393,14 +402,7 @@
|
||||
- [2026-04-20] [specialized-salesforce-architect](sources/specialized-salesforce-architect.md) — (expected: wiki/sources/specialized-salesforce-architect.md — source missing)
|
||||
- [2026-04-20] [lsp-index-engineer](sources/lsp-index-engineer.md) — (expected: wiki/sources/lsp-index-engineer.md — source missing)
|
||||
- [2026-04-20] [corporate-training-designer](sources/corporate-training-designer.md) — (expected: wiki/sources/corporate-training-designer.md — source missing)
|
||||
- [2026-04-20] [specialized-civil-engineer](sources/specialized-civil-engineer.md) — (expected: wiki/sources/specialized-civil-engineer.md — source missing)
|
||||
- [2026-04-20] [project-management-experiment-tracker](sources/project-management-experiment-tracker.md) — (expected: wiki/sources/project-management-experiment-tracker.md — source missing)
|
||||
- [2026-04-20] [automation-governance-architect](sources/automation-governance-architect.md) — (expected: wiki/sources/automation-governance-architect.md — source missing)
|
||||
- [2026-04-20] [project-manager-senior](sources/project-manager-senior.md) — (expected: wiki/sources/project-manager-senior.md — source missing)
|
||||
- [2026-04-20] [project-management-jira-workflow-steward](sources/project-management-jira-workflow-steward.md) — (expected: wiki/sources/project-management-jira-workflow-steward.md — source missing)
|
||||
- [2026-04-20] [project-management-project-shepherd](sources/project-management-project-shepherd.md) — (expected: wiki/sources/project-management-project-shepherd.md — source missing)
|
||||
- [2026-04-20] [project-management-studio-producer](sources/project-management-studio-producer.md) — (expected: wiki/sources/project-management-studio-producer.md — source missing)
|
||||
- [2026-04-20] [visionos-spatial-engineer](sources/visionos-spatial-engineer.md) — (expected: wiki/sources/visionos-spatial-engineer.md — source missing)
|
||||
- [2026-04-20] [specialized-model-qa](sources/specialized-model-qa.md) — (expected: wiki/sources/specialized-model-qa.md — source missing)
|
||||
- [2026-04-20] [specialized-cultural-intelligence-strategist](sources/specialized-cultural-intelligence-strategist.md) — (expected: wiki/sources/specialized-cultural-intelligence-strategist.md — source missing)
|
||||
- [2026-04-20] [healthcare-marketing-compliance](sources/healthcare-marketing-compliance.md) — (expected: wiki/sources/healthcare-marketing-compliance.md — source missing)
|
||||
@@ -411,8 +413,6 @@
|
||||
- [2026-04-20] [specialized-document-generator](sources/specialized-document-generator.md) — (expected: wiki/sources/specialized-document-generator.md — source missing)
|
||||
- [2026-04-20] [identity-graph-operator](sources/identity-graph-operator.md) — (expected: wiki/sources/identity-graph-operator.md — source missing)
|
||||
- [2026-04-20] [accounts-payable-agent](sources/accounts-payable-agent.md) — (expected: wiki/sources/accounts-payable-agent.md — source missing)
|
||||
- [2026-04-20] [recruitment-specialist](sources/recruitment-specialist.md) — (expected: wiki/sources/recruitment-specialist.md — source missing)
|
||||
- [2026-04-20] [project-management-studio-operations](sources/project-management-studio-operations.md) — (expected: wiki/sources/project-management-studio-operations.md — source missing)
|
||||
- [2026-04-20] [baoyu-skills](sources/baoyu-skills.md) — (expected: wiki/sources/baoyu-skills.md — source missing)
|
||||
- [Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog](sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md) — (expected: wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md — source missing)
|
||||
- [Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend](sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md) — (expected: wiki/sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md — source missing)
|
||||
@@ -533,12 +533,14 @@
|
||||
- [engineering-ai-data-remediation-engineer](sources/engineering-ai-data-remediation-engineer.md) — (expected: wiki/sources/engineering-ai-data-remediation-engineer.md — source missing)
|
||||
|
||||
## Entities
|
||||
- [ACI-318](entities/ACI-318.md)
|
||||
- [Acronis](entities/Acronis.md)
|
||||
- [AdamSmith](entities/AdamSmith.md)
|
||||
- [ADK](entities/ADK.md)
|
||||
- [AdsPower](entities/AdsPower.md)
|
||||
- [Agentic-AI](entities/Agentic-AI.md)
|
||||
- [AionUi](entities/AionUi.md)
|
||||
- [AISC-360](entities/AISC-360.md)
|
||||
- [aitmpl.com](entities/aitmpl.com.md)
|
||||
- [Alertmanager](entities/Alertmanager.md)
|
||||
- [Alex-Ewerlof](entities/Alex-Ewerlof.md)
|
||||
@@ -560,6 +562,7 @@
|
||||
- [Anthropic](entities/Anthropic.md)
|
||||
- [Apache-Superset](entities/Apache-Superset.md)
|
||||
- [Asana](entities/Asana.md)
|
||||
- [ASCE-7](entities/ASCE-7.md)
|
||||
- [Ashish](entities/Ashish.md)
|
||||
- [Atlantis](entities/Atlantis.md)
|
||||
- [AWS](entities/AWS.md)
|
||||
@@ -574,6 +577,7 @@
|
||||
- [bitwarden](entities/bitwarden.md)
|
||||
- [blackbox-exporter](entities/blackbox-exporter.md)
|
||||
- [BMC](entities/BMC.md)
|
||||
- [BossZhipin](entities/BossZhipin.md)
|
||||
- [Bottlerocket](entities/Bottlerocket.md)
|
||||
- [bottom](entities/bottom.md)
|
||||
- [Brendan-Starnig](entities/Brendan-Starnig.md)
|
||||
@@ -619,12 +623,14 @@
|
||||
- [DracoVibeCoding](entities/DracoVibeCoding.md)
|
||||
- [DXC-VSM](entities/DXC-VSM.md)
|
||||
- [EESJGong](entities/EESJGong.md)
|
||||
- [Eurocode](entities/Eurocode.md)
|
||||
- [fireworks-tech-graph](entities/fireworks-tech-graph.md)
|
||||
- [Flux](entities/Flux.md)
|
||||
- [frp](entities/frp.md)
|
||||
- [Gamma-AI](entities/Gamma-AI.md)
|
||||
- [GDPR](entities/GDPR.md)
|
||||
- [Gitea](entities/Gitea.md)
|
||||
- [Gitmoji](entities/Gitmoji.md)
|
||||
- [glances](entities/glances.md)
|
||||
- [gog](entities/gog.md)
|
||||
- [gog-CLI](entities/gog-CLI.md)
|
||||
@@ -651,6 +657,7 @@
|
||||
- [Jay-Comer](entities/Jay-Comer.md)
|
||||
- [Jellyfin](entities/Jellyfin.md)
|
||||
- [Jira](entities/Jira.md)
|
||||
- [Jira-Workflow-Steward](entities/Jira-Workflow-Steward.md)
|
||||
- [JohnWilliams](entities/JohnWilliams.md)
|
||||
- [K3s](entities/K3s.md)
|
||||
- [KAI](entities/KAI.md)
|
||||
@@ -664,6 +671,7 @@
|
||||
- [LinkedIn-Campaign-Manager](entities/LinkedIn-Campaign-Manager.md)
|
||||
- [LinuxServer.io](entities/LinuxServer.io.md)
|
||||
- [Mac-Mini-M4](entities/Mac-Mini-M4.md)
|
||||
- [macOS-Spatial-Metal-Engineer](entities/macOS-Spatial-Metal-Engineer.md)
|
||||
- [Manus](entities/Manus.md)
|
||||
- [MariaDB](entities/MariaDB.md)
|
||||
- [Martin-Nash](entities/Martin-Nash.md)
|
||||
@@ -711,6 +719,7 @@
|
||||
- [Portainer](entities/Portainer.md)
|
||||
- [Prismer-AI](entities/Prismer-AI.md)
|
||||
- [Product-Security-Group](entities/Product-Security-Group.md)
|
||||
- [Project-Management-Experiment-Tracker](entities/Project-Management-Experiment-Tracker.md)
|
||||
- [Prometheus](entities/Prometheus.md)
|
||||
- [Public-Cloud-Provider](entities/Public-Cloud-Provider.md)
|
||||
- [Qdrant](entities/Qdrant.md)
|
||||
@@ -736,6 +745,7 @@
|
||||
- [SRE-Team](entities/SRE-Team.md)
|
||||
- [Stable-Diffusion](entities/Stable-Diffusion.md)
|
||||
- [stacer](entities/stacer.md)
|
||||
- [Studio-Producer](entities/Studio-Producer.md)
|
||||
- [Suravpul](entities/Suravpul.md)
|
||||
- [SurfSense](entities/SurfSense.md)
|
||||
- [Swinford.net](entities/Swinford.net.md)
|
||||
@@ -761,6 +771,9 @@
|
||||
- [Vinay](entities/Vinay.md)
|
||||
- [VMware](entities/VMware.md)
|
||||
- [WildCard](entities/WildCard.md)
|
||||
- [XR-Cockpit-Interaction-Specialist](entities/XR-Cockpit-Interaction-Specialist.md)
|
||||
- [XR-Immersive-Developer](entities/XR-Immersive-Developer.md)
|
||||
- [XR-Interface-Architect](entities/XR-Interface-Architect.md)
|
||||
- [YishenTu](entities/YishenTu.md)
|
||||
- [Zipline](entities/Zipline.md)
|
||||
- [余梦珑](entities/余梦珑.md)
|
||||
@@ -819,6 +832,7 @@
|
||||
- [APT-仓库配置](concepts/APT-仓库配置.md)
|
||||
- [arXiv-API](concepts/arXiv-API.md)
|
||||
- [Asset-Management](concepts/Asset-Management.md)
|
||||
- [Atomic-Commit](concepts/Atomic-Commit.md)
|
||||
- [Attach容器](concepts/Attach容器.md)
|
||||
- [Attention-Economy](concepts/Attention-Economy.md)
|
||||
- [Audit-Trail](concepts/Audit-Trail.md)
|
||||
@@ -835,6 +849,7 @@
|
||||
- [Blue-Green-Deployment](concepts/Blue-Green-Deployment.md)
|
||||
- [BOOTSTRAP.md](concepts/BOOTSTRAP.md.md)
|
||||
- [Brain-Dump](concepts/Brain-Dump.md)
|
||||
- [Branch-Strategy](concepts/Branch-Strategy.md)
|
||||
- [Brand-Environment](concepts/Brand-Environment.md)
|
||||
- [Break-the-Build](concepts/Break-the-Build.md)
|
||||
- [Bug-Bounty](concepts/Bug-Bounty.md)
|
||||
@@ -857,6 +872,7 @@
|
||||
- [Change-Management](concepts/Change-Management.md)
|
||||
- [Channel-Based-Monitoring](concepts/Channel-Based-Monitoring.md)
|
||||
- [Check-in-Fatigue](concepts/Check-in-Fatigue.md)
|
||||
- [ChinaLaborLawCompliance](concepts/ChinaLaborLawCompliance.md)
|
||||
- [CI-CD-Pipeline](concepts/CI-CD-Pipeline.md)
|
||||
- [CICDPipeline](concepts/CICDPipeline.md)
|
||||
- [CIS-Benchmark](concepts/CIS-Benchmark.md)
|
||||
@@ -919,6 +935,7 @@
|
||||
- [DealHealthScoring](concepts/DealHealthScoring.md)
|
||||
- [Defense-in-Depth](concepts/Defense-in-Depth.md)
|
||||
- [Defuddle](concepts/Defuddle.md)
|
||||
- [Delivery-Traceability](concepts/Delivery-Traceability.md)
|
||||
- [Demo-Engineering](concepts/Demo-Engineering.md)
|
||||
- [Dependency-Management](concepts/Dependency-Management.md)
|
||||
- [Deployment-Automation](concepts/Deployment-Automation.md)
|
||||
@@ -986,6 +1003,7 @@
|
||||
- [Genetic-Algorithm](concepts/Genetic-Algorithm.md)
|
||||
- [GitAsAuditLog](concepts/GitAsAuditLog.md)
|
||||
- [GitHub-Release-Monitoring](concepts/GitHub-Release-Monitoring.md)
|
||||
- [Gitmoji-Commit](concepts/Gitmoji-Commit.md)
|
||||
- [GitOps](concepts/GitOps.md)
|
||||
- [GPG-密钥验证](concepts/GPG-密钥验证.md)
|
||||
- [Green-Computing](concepts/Green-Computing.md)
|
||||
@@ -1018,6 +1036,7 @@
|
||||
- [Incrementality-Testing](concepts/Incrementality-Testing.md)
|
||||
- [Indexing](concepts/Indexing.md)
|
||||
- [Infrastructure-as-Code](concepts/Infrastructure-as-Code.md)
|
||||
- [Innovation-Pipeline](concepts/Innovation-Pipeline.md)
|
||||
- [Intent-Classification](concepts/Intent-Classification.md)
|
||||
- [Intentional-Cloud-Strategy](concepts/Intentional-Cloud-Strategy.md)
|
||||
- [Inversion](concepts/Inversion.md)
|
||||
@@ -1026,6 +1045,8 @@
|
||||
- [ITSM](concepts/ITSM.md)
|
||||
- [ITSM-2.0](concepts/ITSM-2.0.md)
|
||||
- [JFFS双清](concepts/JFFS双清.md)
|
||||
- [Jira-Gate](concepts/Jira-Gate.md)
|
||||
- [Jira-Git-Traceability](concepts/Jira-Git-Traceability.md)
|
||||
- [Kanban](concepts/Kanban.md)
|
||||
- [Keyword-Based-Monitoring](concepts/Keyword-Based-Monitoring.md)
|
||||
- [Kill-Switch](concepts/Kill-Switch.md)
|
||||
@@ -1044,6 +1065,7 @@
|
||||
- [Lead-Time](concepts/Lead-Time.md)
|
||||
- [Learn-By-Building](concepts/Learn-By-Building.md)
|
||||
- [Left-over-Principle](concepts/Left-over-Principle.md)
|
||||
- [Liquid-Glass-Design-System](concepts/Liquid-Glass-Design-System.md)
|
||||
- [LLM-Wiki](concepts/LLM-Wiki.md)
|
||||
- [Local-Caching](concepts/Local-Caching.md)
|
||||
- [Local-first-Git](concepts/Local-first-Git.md)
|
||||
@@ -1075,7 +1097,9 @@
|
||||
- [Multi-Database-Architecture](concepts/Multi-Database-Architecture.md)
|
||||
- [Multi-factor-Authentication](concepts/Multi-factor-Authentication.md)
|
||||
- [Multi-Tenancy](concepts/Multi-Tenancy.md)
|
||||
- [Multi-Window-Architecture](concepts/Multi-Window-Architecture.md)
|
||||
- [nas套件管理](concepts/nas套件管理.md)
|
||||
- [National-Annex](concepts/National-Annex.md)
|
||||
- [NegativePromptingLibrary](concepts/NegativePromptingLibrary.md)
|
||||
- [Net-Revenue-Retention](concepts/Net-Revenue-Retention.md)
|
||||
- [NFS网络备份](concepts/NFS网络备份.md)
|
||||
@@ -1109,6 +1133,7 @@
|
||||
- [POC-Scoping](concepts/POC-Scoping.md)
|
||||
- [Pod-Security-Context](concepts/Pod-Security-Context.md)
|
||||
- [Policy-as-Code](concepts/Policy-as-Code.md)
|
||||
- [Portfolio-ROI](concepts/Portfolio-ROI.md)
|
||||
- [PRD生成工作流](concepts/PRD生成工作流.md)
|
||||
- [Pre-Build-Validation](concepts/Pre-Build-Validation.md)
|
||||
- [Predictive-Maintenance](concepts/Predictive-Maintenance.md)
|
||||
@@ -1125,12 +1150,15 @@
|
||||
- [proxychains](concepts/proxychains.md)
|
||||
- [Public-Cloud](concepts/Public-Cloud.md)
|
||||
- [PUID-PGID](concepts/PUID-PGID.md)
|
||||
- [Pull-Request-Governance](concepts/Pull-Request-Governance.md)
|
||||
- [Purpose-Built-Databases](concepts/Purpose-Built-Databases.md)
|
||||
- [Quality-Scoring-Algorithm](concepts/Quality-Scoring-Algorithm.md)
|
||||
- [QualityAdjustedCoverage](concepts/QualityAdjustedCoverage.md)
|
||||
- [RAG](concepts/RAG.md)
|
||||
- [Reality-Signal](concepts/Reality-Signal.md)
|
||||
- [RealityKit-SwiftUI-Integration](concepts/RealityKit-SwiftUI-Integration.md)
|
||||
- [Reciprocal-Rank-Fusion](concepts/Reciprocal-Rank-Fusion.md)
|
||||
- [RecruitmentFunnelAnalyzer](concepts/RecruitmentFunnelAnalyzer.md)
|
||||
- [Recurring-Task](concepts/Recurring-Task.md)
|
||||
- [Recurring-Tasks](concepts/Recurring-Tasks.md)
|
||||
- [Recursive-Self-Optimization](concepts/Recursive-Self-Optimization.md)
|
||||
@@ -1142,6 +1170,7 @@
|
||||
- [RemoteDevelopment](concepts/RemoteDevelopment.md)
|
||||
- [RemoteRescuePattern](concepts/RemoteRescuePattern.md)
|
||||
- [Renovate-Bot](concepts/Renovate-Bot.md)
|
||||
- [Resource-Allocation](concepts/Resource-Allocation.md)
|
||||
- [ResponsiveSearchAds](concepts/ResponsiveSearchAds.md)
|
||||
- [Retrieval](concepts/Retrieval.md)
|
||||
- [Reviewer](concepts/Reviewer.md)
|
||||
@@ -1191,6 +1220,7 @@
|
||||
- [Signal-Based-Selling-Framework](concepts/Signal-Based-Selling-Framework.md)
|
||||
- [Single-Control-Plane](concepts/Single-Control-Plane.md)
|
||||
- [SKAdNetwork](concepts/SKAdNetwork.md)
|
||||
- [SLS](concepts/SLS.md)
|
||||
- [SmartBidding](concepts/SmartBidding.md)
|
||||
- [SnapMirror](concepts/SnapMirror.md)
|
||||
- [Social-Media-Monitoring](concepts/Social-Media-Monitoring.md)
|
||||
@@ -1201,16 +1231,22 @@
|
||||
- [SOUL.md](concepts/SOUL.md.md)
|
||||
- [Source-Grounding](concepts/Source-Grounding.md)
|
||||
- [Spatial-Computing](concepts/Spatial-Computing.md)
|
||||
- [Spatial-Widgets](concepts/Spatial-Widgets.md)
|
||||
- [Split](concepts/Split.md)
|
||||
- [Spot-Instances](concepts/Spot-Instances.md)
|
||||
- [SSE-Server-Sent-Events](concepts/SSE-Server-Sent-Events.md)
|
||||
- [StackSets-Deployment-Visibility](concepts/StackSets-Deployment-Visibility.md)
|
||||
- [Stakeholder-Alignment](concepts/Stakeholder-Alignment.md)
|
||||
- [Standard-Change](concepts/Standard-Change.md)
|
||||
- [STARFramework](concepts/STARFramework.md)
|
||||
- [Startup-MVP-Pipeline](concepts/Startup-MVP-Pipeline.md)
|
||||
- [Strategic-Portfolio-Management](concepts/Strategic-Portfolio-Management.md)
|
||||
- [Streak-Tracking](concepts/Streak-Tracking.md)
|
||||
- [Stretched-Cluster](concepts/Stretched-Cluster.md)
|
||||
- [StructuredInterview](concepts/StructuredInterview.md)
|
||||
- [StudyVault](concepts/StudyVault.md)
|
||||
- [Sub-Agent-Race-Condition](concepts/Sub-Agent-Race-Condition.md)
|
||||
- [SwiftUI-Volumetric-APIs](concepts/SwiftUI-Volumetric-APIs.md)
|
||||
- [symbolic-link](concepts/symbolic-link.md)
|
||||
- [System-Economy](concepts/System-Economy.md)
|
||||
- [system-monitoring](concepts/system-monitoring.md)
|
||||
@@ -1246,6 +1282,7 @@
|
||||
- [Two-Way-Voice-Conversation](concepts/Two-Way-Voice-Conversation.md)
|
||||
- [UEFI-Only](concepts/UEFI-Only.md)
|
||||
- [UEFI启动](concepts/UEFI启动.md)
|
||||
- [ULS](concepts/ULS.md)
|
||||
- [Unified-Inbox](concepts/Unified-Inbox.md)
|
||||
- [USER.md](concepts/USER.md.md)
|
||||
- [Variables-YAML](concepts/Variables-YAML.md)
|
||||
|
||||
85
wiki/log.md
85
wiki/log.md
@@ -1,3 +1,79 @@
|
||||
## [2026-04-25] ingest | Specialized Civil Engineer Agent
|
||||
- Source file: Agent/agency-agents/specialized/specialized-civil-engineer.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Civil Engineer Agent——全球设计标准覆盖的结构与土木工程专家 Agent，驾驭 Eurocode（EN 1990–1999 + 各国 National Annex）、ACI 318（LRFD/SD）、AISC 360、ASCE 7、GB/IS/AIJ 等全球主流建筑规范体系。核心方法：ULS+SLS 双重验证、多标准冲突处理（识别→记录→保守优先→Basis of Design）、岩土工程全流程。计算交付物：钢梁 AISC 360 LRFD 计算包、RC 梁 Eurocode EN 1992-1-1 计算包、Terzaghi 岩土地基承载力分析。六阶段工作流：项目范围→初步设计→详细计算→建造文档→规范合规→施工支持。
|
||||
- Concepts created: [[ULS]], [[SLS]], [[National-Annex]], [[LRFD]], [[Basis-of-Design]], [[BIM-Coordination]], [[Ductility-Class]]
|
||||
- Entities created: [[Eurocode]], [[AISC-360]], [[ACI-318]], [[ASCE-7]], [[EN-1997]], [[AIJ]]
|
||||
- Source page: wiki/sources/specialized-civil-engineer.md
|
||||
- Notes: 无已知冲突。该 Agent 覆盖全球独立规范体系，各标准间差异已明确标注，不可混用。
|
||||
|
||||
- Source file: Agent/agency-agents/project-management/project-management-experiment-tracker.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Experiment Tracker Agent——The Agency 项目管理部门的实验追踪专家 Agent，专注于 A/B 测试、功能实验和假设验证的科学化管理。核心交付物：实验设计文档模板和实验结果报告模板。成功指标：95% 实验达统计显著性、每季度 15+ 实验、70% 成功率、80% 成功实验落地。高级能力：多臂老虎机、贝叶斯分析、因果推断、ML 模型 A/B 测试。
|
||||
- Concepts created: [[A/B-Testing]], [[Statistical-Significance]], [[Power-Analysis]], [[Hypothesis-Validation]], [[Experiment-Portfolio-Management]], [[Multi-Armed-Bandits]], [[Bayesian-Analysis]], [[Causal-Inference]]
|
||||
- Entities created: [[Project-Management-Experiment-Tracker]]
|
||||
- Source page: wiki/sources/project-management-experiment-tracker.md
|
||||
- Notes: 与 [[Project-Management-Studio-Operations]] 存在潜在张力（实验节奏 vs 内容制作节奏），已记录于 Contradictions
|
||||
|
||||
## [2026-04-25] ingest | Studio Operations Agent Personality
|
||||
- Source file: Agent/agency-agents/project-management/project-management-studio-operations.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Studio Operations Agent——The Agency 项目管理部门的执行层 Agent，专注于工作室日常运营效率、流程优化和资源协调。核心交付物：SOP 模板（四步工作流：评估→协调→实施→监控）和运营效率报告模板。成功指标：95% 运营效率、99.5% 系统正常运行时间、年度成本降低 10%、支持响应时间 < 2 小时。
|
||||
- Concepts created: （本次未创建独立 Concept 页面——文档内各概念（Standard Operating Procedure/Operational Efficiency 等）均与 [[The Agency]] 生态强绑定，不满足可独立复用条件）
|
||||
- Entities created: （本次未创建独立 Entity 页面——文档内唯一实体 [[The Agency]] 在 Wiki 中已有充分引用）
|
||||
- Source page: wiki/sources/project-management-studio-operations.md
|
||||
- Notes: 与 [[project-management-studio-producer]]（战略层）和 [[ProjectManagerSenior]]（任务分解层）构成完整项目管理体系层级；与 [[Project-Management-Jira-Workflow-Steward]] 和 [[Project-Management-Project-Shepherd]] 协同；index.md 中标记的 expected 条目已补全
|
||||
|
||||
## [2026-04-25] ingest | Senior Project Manager Agent Personality
|
||||
- Source file: Agent/agency-agents/project-management/project-manager-senior.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Senior Project Manager——The Agency 项目管理部门的执行层 Agent，专注于将网站规格文档（site-setup.md）精准转化为 30-60 分钟可执行开发任务列表。核心方法：精确引用规格原则 + 务实范围控制（拒绝 luxury/premium 除非明确）+ 开发者优先任务描述。核心约束：不添加后台进程、不启动开发服务器、必须包含 Playwright 截图测试。
|
||||
- Concepts created: （本次未创建独立 Concept 页面——文档内各概念均仅出现 1 次，不满足 ≥ 2 次创建门槛）
|
||||
- Entities created: （本次未创建独立 Entity 页面——文档内各实体均仅出现 1 次，不满足 ≥ 2 次创建门槛）
|
||||
- Contradictions detected: 与 [[Project-Management-Project-Shepherd]] 存在职责边界张力——Senior PM 关注任务拆解细节，Shepherd 关注项目整体把控；两者形成执行层与规划层的协作关系，记录于 Source Page Contradictions 部分
|
||||
- Source page: wiki/sources/project-manager-senior.md
|
||||
- Notes: index.md 占位符条目已替换（添加中文摘要）；overview.md 已补充 [[ProjectManagerSenior]] 独立段落，完善了项目管理层级的战略-执行协作关系描述
|
||||
|
||||
## [2026-04-25] ingest | Jira Workflow Steward Agent Personality
|
||||
- Source file: Agent/agency-agents/project-management/project-management-jira-workflow-steward.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Jira Workflow Steward——交付纪律守护者 Agent，通过 Jira-Git 全链路绑定（Task→Branch→Commit→PR→Release）确保代码交付可审查、可回滚、可审计。核心机制：Jira Gate（无 Jira ID 则停止工作流）+ 分支策略（feature/bugfix/hotfix/release）+ Gitmoji 规范提交 + PR 模板 + Commit Hook 自动化验证。定位：Jira-linked commits 是质量工具而非合规打勾。
|
||||
- Concepts created: [[Jira-Git-Traceability]], [[Atomic-Commit]], [[Branch-Strategy]], [[Gitmoji-Commit]], [[Jira-Gate]], [[Pull-Request-Governance]], [[Delivery-Traceability]]
|
||||
- Entities created: [[Jira-Workflow-Steward]], [[Gitmoji]]
|
||||
- Contradictions detected: 与 [[Project-Management-Project-Shepherd]] 在职责边界存在互补张力——Steward 严格 gate（Jira ID 前置），若 Shepherd 未预创建任务则工作流中断，建议在 Shepherd 端增加预创建步骤；与 [[Project-Management-Studio-Producer]] 在交付粒度上属不同抽象层级（原子 commit vs 组合 Epic/Story），无直接冲突
|
||||
- Source page: wiki/sources/project-management-jira-workflow-steward.md
|
||||
- Notes: 7 个 Concept 页面已创建并添加到 index.md；2 个 Entity 页面已创建（Jira-Workflow-Steward/Gitmoji）并添加到 index.md；source page 已添加与 Project-Management-Project-Shepherd 和 Studio-Producer 的跨文档矛盾记录；index.md 占位符条目已替换（2026-04-20 → 2026-04-25，添加中文摘要）
|
||||
|
||||
## [2026-04-25] ingest | Project Shepherd Agent Personality
|
||||
- Source file: Agent/agency-agents/project-management/project-management-project-shepherd.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Project Shepherd——AI Agent 项目管理人格，专职跨职能项目协调、时间线管理、干系人对齐与风险缓解。四阶段工作流：项目启动→团队组建→执行监控→质量交付。核心交付物：Project Charter 模板、Status Report 模板、风险缓解框架。成功指标：95% 按时交付、范围蔓延 < 10%、90% 风险提前缓解、干系人满意度 4.5/5。
|
||||
- Concepts created: （本次未创建独立 Concept 页面——文档内各概念均仅出现 1 次，不满足 ≥ 2 次创建门槛）
|
||||
- Entities created: （本次未创建独立 Entity 页面——文档内各实体均仅出现 1 次，不满足 ≥ 2 次创建门槛）
|
||||
- Contradictions detected: 无。本文档与 [[Project-Management-Studio-Operations]] 和 [[Project-Management-Senior]] 在项目管理层级上互补而非冲突，属层级差异。
|
||||
- Source page: wiki/sources/project-management-project-shepherd.md
|
||||
- Notes: index.md 占位符条目已替换（2026-04-20 → 2026-04-25，添加中文摘要）；overview.md 第 65 行已包含 [[Project-Management-Project-Shepherd]] wikilink（项目管理层级链一环），无需额外修订
|
||||
|
||||
## [2026-04-25] ingest | Studio Producer Agent Personality
|
||||
- Source file: Agent/agency-agents/project-management/project-management-studio-producer.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Studio Producer——The Agency 项目管理部门的高管级战略领导者 Agent，专注于创意愿景与商业目标对齐的组合管理。核心职责：战略组合规划（Tier 1/2/Innovation Pipeline 三级）、Portfolio ROI 管理（≥ 25%）、95% 按时交付率、高管级利益相关者沟通。四阶段工作流：战略规划→项目编排→领导力发展→绩效优化。
|
||||
- Concepts created: [[Strategic-Portfolio-Management]], [[Resource-Allocation]], [[Portfolio-ROI]], [[Innovation-Pipeline]], [[Stakeholder-Alignment]]
|
||||
- Entities created: [[Studio-Producer]]
|
||||
- Contradictions detected: 与 [[Project-Management-Studio-Operations]] 在战略（Producer）与运营（Operations）的权责边界存在张力，需通过 Portfolio Review 机制对齐；与 [[Project-Manager-Senior]] 的管理广度差异（组合 vs 单项目）属层级差异而非矛盾
|
||||
- Source page: wiki/sources/project-management-studio-producer.md
|
||||
- Notes: 已在 overview.md 新增 "The Agency — Project Management 部门" 章节（位于 Paid Media 部门之前），包含 Studio Producer 完整段落及与其他项目管理 Agent 的层级关系描述；5 个 Concept 页面已创建；index.md 中 source 条目已替换（2026-04-20 → 2026-04-25）；Studio-Producer Entity 页面已创建并添加至 index.md
|
||||
|
||||
## [2026-04-25] ingest | visionOS Spatial Engineer Agent Personality
|
||||
- Source file: Agent/agency-agents/spatial-computing/visionos-spatial-engineer.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: visionOS Spatial Engineer——Apple visionOS 26 原生空间计算 Agent，专注于 SwiftUI volumetric interfaces 和 Liquid Glass Design System 实现。核心能力：Liquid Glass 透明材质设计、Spatial Widgets、SwiftUI Volumetric APIs、RealityKit-SwiftUI 集成、Multi-Window Architecture、GPU 高效渲染。技术栈：SwiftUI / RealityKit / ARKit / Metal。
|
||||
- Concepts created: [[Liquid-Glass-Design-System]], [[Spatial-Widgets]], [[SwiftUI-Volumetric-APIs]], [[RealityKit-SwiftUI-Integration]], [[Multi-Window-Architecture]]
|
||||
- Entities created: [[XR-Interface-Architect]], [[XR-Immersive-Developer]], [[XR-Cockpit-Interaction-Specialist]], [[macOS-Spatial-Metal-Engineer]]
|
||||
- Contradictions detected: 与 [[XR-Immersive-Developer]] 在平台选择上存在差异（WebXR 跨平台 vs visionOS 原生独占），已记录于 Source Page Contradictions 部分；与 [[macOS-Spatial-Metal-Engineer]] 在技术栈选择上存在张力（SwiftUI 声明式 vs Metal 底层渲染），已记录为互补关系
|
||||
- Source page: wiki/sources/visionos-spatial-engineer.md
|
||||
- Notes: index.md 已替换占位符条目（2026-04-20 → 2026-04-25，添加摘要描述）；overview.md 已新增独立段落（位于 macOS Spatial/Metal Engineer 段落后）；5 个 Concept 页面已创建并添加到 index.md；4 个 Entity 页面已创建（XR-Interface-Architect/XR-Immersive-Developer/XR-Cockpit-Interaction-Specialist/macOS-Spatial-Metal-Engineer）并添加到 index.md；相关 Entity 和 Concept 页面的 sources 列表已更新
|
||||
|
||||
## [2026-04-25] ingest | XR Interface Architect Agent Personality
|
||||
- Source file: Agent/agency-agents/spatial-computing/xr-interface-architect.md
|
||||
- Status: ✅ 成功摄入
|
||||
@@ -2897,3 +2973,12 @@
|
||||
- Entities linked: [[Apple]], [[Vision Pro]], [[Metal]], [[Xcode Instruments]], [[RealityKit]], [[ARKit]]
|
||||
- Source page: wiki/sources/macos-spatial-metal-engineer.md
|
||||
- Notes: Entity 层面 Apple/Vision Pro/Metal/Xcode Instruments/RealityKit/ARKit 在源文档中提及但均不足独立建页阈值，通过 Sources 页面的 Key Entities 部分建立链接；与 [[visionos-spatial-engineer]] 存在职责重叠（Vision Pro 开发），已记录于 Contradictions 部分——前者侧重 macOS 渲染侧 + Vision Pro 流式输出，后者倾向 visionOS 原生交互开发，两者可协同；与 [[xr-immersive-developer]] 互补——浏览器端 WebXR vs Apple 原生 Metal 渲染管线，共同构成 XR 产品矩阵
|
||||
|
||||
## [2026-04-25] ingest | Recruitment Specialist Agent
|
||||
- Source file: Agent/agency-agents/specialized/recruitment-specialist.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: RecruitmentSpecialist 是一个专注于中国人力资源市场的招聘运营与人才获取专家 Agent，覆盖从人才吸引、入职到留任的全周期招聘引擎。涵盖中国招聘平台运营（BOSS直聘、拉勾、猎聘、智联、前程无忧、脉脉、LinkedIn）、JD 优化、简历筛选、面试流程设计（STAR、结构化面试）、校园招聘、猎头管理、劳动法合规（劳动合同法、PIPL、五险一金、N+1）、雇主品牌建设、入职 SOP、招聘数据分析全链路。
|
||||
- Concepts created: [[STAR Framework]], [[Structured Interview]], [[China Labor Law Compliance]], [[Recruitment Funnel Analyzer]]
|
||||
- Entities created: [[Boss Zhipin]]
|
||||
- Source page: wiki/sources/recruitment-specialist.md
|
||||
- Notes: 无已知冲突。Key Entities 中 Lagou/Liepin/Beisen/Moka/Feishu/STAR 等在源文档出现但出现次数不足以触发独立建页，通过 Sources 页面的 Key Entities 部分建立 wikilinks。
|
||||
|
||||
@@ -57,6 +57,19 @@ The wiki covers two major multi-agent frameworks: **The Agency** (agency-agents)
|
||||
|
||||
**[[macos-spatial-metal-engineer]]**（macOS Spatial/Metal Engineer）：Apple 平台专用 Metal 渲染与空间计算 Agent——专注于 Swift + Metal 的高性能 3D 渲染系统和 visionOS 空间计算体验。核心能力：实例化 Metal 渲染（Instanced Rendering）驱动 10k-100k 节点图数据，目标 90fps 立体渲染；通过 RemoteImmersiveSpace 和 LayerRenderer（stereo 模式、RGBA16Float + Depth32Float）实现 macOS 到 Vision Pro 的帧流传输；Metal Compute Shader 执行 GPU 并行力导向图物理模拟（排斥力 + 吸引力 + 阻尼）；注视（Gaze）+ 捏合（Pinch）空间交互与 raycast hit testing。性能约束：GPU 利用率 < 80%、每帧 < 100 draw calls、内存 < 1GB。与 [[xr-immersive-developer]] 互补——前者专注浏览器端 WebXR，后者专注 Apple 原生 Metal 渲染管线；与 [[visionos-spatial-engineer]] 存在职责张力——后者倾向 visionOS 原生开发，前者侧重 macOS 渲染侧 + Vision Pro 流式输出，两者协同构成完整的 Apple 空间计算平台能力。属 [[Spatial-Computing]] 概念在 Apple 原生平台场景的具体实现。
|
||||
|
||||
**[[visionos-spatial-engineer]]**（visionOS Spatial Engineer）：Apple visionOS 原生空间计算 Agent——专注于 visionOS 26 平台的 SwiftUI volumetric interfaces 和 Liquid Glass Design System 实现。核心能力：Liquid Glass 透明材质设计（自适应 light/dark 环境）、Spatial Widgets（吸附墙面/桌面、持久化放置）、SwiftUI Volumetric APIs（3D 内容集成、volume transient content、breakthrough UI）、RealityKit-SwiftUI 集成（Observable entities、直接手势处理、ViewAttachmentComponent）、Multi-Window Architecture（WindowGroup 管理、玻璃背景效果）、GPU 高效渲染。技术栈：SwiftUI / RealityKit / ARKit / Metal。典型交付物：visionOS 原生空间应用、volumetric 界面、Liquid Glass 体验。与 [[macos-spatial-metal-engineer]] 协同——前者专注 UI/UX 层应用开发，后者专注 GPU 密集型数据渲染，共同构成完整的 Apple 空间计算平台能力。属 [[Spatial-Computing]] 概念在 Apple 原生平台场景的具体实现。
|
||||
|
||||
### The Agency — Project Management 部门
|
||||
|The Agency 的 Project Management 部门涵盖多个垂直领域的专业项目管理 Agent，从战略组合管理到实验跟踪，覆盖项目全生命周期。|
|
||||
|
||||
**[[project-management-studio-producer]]**（Studio Producer）：高管级战略领导者 Agent——The Agency 项目管理部门的组合管理专家，专注于创意愿景与商业目标对齐的多项目战略管理。核心职责：战略组合规划（Tier 1/2/Innovation Pipeline 三级分级）、Portfolio ROI 管理（要求 ≥ 25%）、95% 按时交付率、高管级利益相关者沟通、风险平衡与财务管控。四阶段工作流：战略规划→项目编排→领导力发展→绩效优化。成功指标：Portfolio ROI ≥ 25%、95% 按时交付、客户满意度 4.8/5、市场排名前三、团队绩效超行业基准。与 [[Project-Management-Studio-Operations]] 协同——Producer 负责战略规划，Operations 负责执行落地；与 [[Project-Manager-Senior]]（执行层任务分解）互补——Studio Producer 关注组合层面的资源分配与优先级排序，Senior PM 关注单项目内部的需求到任务的精确映射，共同构成战略-执行协作闭环。属 Agency 项目管理体系中最高战略层级，与 [[Project-Manager-Senior]]（执行层）→ [[Project-Management-Jira-Workflow-Steward]]（流程治理）→ [[Project-Management-Project-Shepherd]]（项目看护）→ [[Project-Management-Experiment-Tracker]]（实验跟踪）共同构成完整项目管理层级。
|
||||
|
||||
**[[Project-Management-Studio-Operations]]**（Studio Operations）：日常运营效率与流程优化专家 Agent——The Agency 项目管理部门的执行层 Agent，专注于工作室日常运营效率、流程优化和资源协调，确保 95% 运营效率目标达成。核心职责：SOP 文档化与版本控制（分步程序+质量检查点+升级机制）、资源分配调度和设备技术维护、成本优化与供应商关系管理、运营指标追踪与持续改进。四阶段工作流：流程评估与设计→资源协调管理→实施与团队支持→监控与持续改进。核心交付物：SOP 模板（概述/前提条件/分步程序/质量控制/文档记录）、运营效率报告模板（执行摘要/绩效指标/流程改进/持续改进计划）。成功指标：95% 运营效率、99.5% 系统正常运行时间、团队满意度 4.5/5、年度成本降低 10%、支持响应时间 < 2 小时。与 [[project-management-studio-producer]]（战略层）协同——Producer 负责战略规划，Studio Operations 负责执行落地；与 [[ProjectManagerSenior]] 协同——Senior PM 产出任务列表，Studio Operations 负责执行调度和运营支持；属 Agency 项目管理体系中执行支撑层级，与 Studio Producer（战略层）→ Senior PM（执行层任务分解）→ Studio Operations（执行支撑）共同构成完整项目管理体系。
|
||||
|
||||
**[[ProjectManagerSenior]]**（Senior Project Manager）：单项目任务分解专家 Agent——The Agency 项目管理部门的执行层 Agent，专注于将网站规格文档（site-setup.md）精准转化为 30-60 分钟可执行开发任务列表。核心方法：**精确引用规格原则**（逐字引用原始需求而非主观添加）、**务实范围控制**（默认基础实现即可接受，拒绝 luxury/premium 功能，除非规格明确）、**开发者优先原则**（任务描述具体到可直接交给开发者的程度）。典型交付物：任务列表保存至 `ai/memory-bank/tasks/[project-slug]-tasklist.md`，每任务包含验收标准、涉及文件列表和规格引用。技术栈要求提取：CSS 框架、FluxUI 组件规格、Laravel/Livewire 集成需求。核心价值：**消除规格到任务之间的翻译损耗**，通过"精确引用+粒度控制+务实范围"三原则防止项目范围蔓延（scope creep）。与 [[Project-Management-Studio-Operations]] 互补——Senior PM 产出任务列表，Studio Operations 负责执行调度；与 [[Project-Management-Jira-Workflow-Steward]] 协同——Jira 工作流编排基于 Senior PM 产出的任务列表执行；与 [[ProjectManagerSenior]] 在知识图谱中等同于 [[ProjectManagerSenior]]。
|
||||
|
||||
**[[Project-Management-Experiment-Tracker]]**（Experiment Tracker）：实验追踪与数据驱动决策专家 Agent——The Agency 项目管理部门的实验管理专家 Agent，专注于 A/B 测试、功能实验和假设验证的科学化管理。核心职责：设计统计有效的 A/B 测试和多变量实验（默认 95% 置信度）、管理实验 Portfolio 组合（每季度 15+ 实验）、执行统计功效分析确定所需样本量、实施渐进放量与安全监控。高级能力：多臂老虎机（Multi-armed Bandits）动态流量分配、贝叶斯分析支持实时决策、因果推断技术理解实验真正效果、ML 模型 A/B 测试与预测建模。典型交付物：实验设计文档模板（假设/设计/风险评估/实施计划）、实验结果报告模板（统计结果/置信区间/业务影响/决策建议）。成功指标：95% 实验达统计显著性、70% 实验成功率、80% 成功实验实现落地。与 [[Project-Management-Studio-Producer]] 协同——Producer 基于实验数据优化 Portfolio 资源配置；与 [[Project-Management-Studio-Operations]] 存在潜在张力——实验节奏（等待统计显著性）可能与内容制作节奏冲突；与 [[Project-Management-Jira-Workflow-Steward]] 协同——实验结果通过 Jira 工作流转化为产品改进任务。属 Agency 项目管理体系中的实验验证层级，补充了从战略规划→任务分解→实验验证→流程治理的完整闭环。
|
||||
|
||||
### The Agency — Paid Media 部门
|
||||
The Agency 的 Paid Media 部门专注于企业级付费媒体策略与运营，涵盖 Google Ads、Microsoft Advertising、Amazon Ads 三大核心平台。
|
||||
|
||||
@@ -657,6 +670,10 @@ Key concepts: [[Django ORM]], [[Django REST Framework]], [[Django Admin 定制]]
|
||||
|
||||
**[[sales-engineer]]**（Sales Engineer Agent）：售前工程师 Agent，专注于在 B2B 技术评估中赢得技术决策——核心理念：技术决策先于商业合同，售前工程师必须将每一次技术对话连接到业务成果，而非单纯展示功能。核心能力：**Demo Engineering**（以影响力为导向的演示设计：先量化问题→展示结果→逆向讲解→证明收尾，以 [[AhaMoment]] 为核心成功标准）+ **POC Scoping**（严格限定的概念验证：成功标准明确写在开始前，2-3 周硬性时间线，中期检查点，防止范围蔓延）+ **FIA Framework**（Fact-Impact-Act 竞争定位框架，保持事实基础和可操作性，永远不攻击竞品）+ **技术异议解码**（识别"是否支持 SSO？"背后的真实关切是"能否通过安全审查"，从根源回应而非表面处理）+ **评估笔记维护**（结构化记录每个活跃交易的技术环境、决策者、竞争态势和演示策略）。成功指标：技术赢率 70%+，POC 转化率 80%+，演示到下一步行动率 90%+，中位数 18 天技术决策。与 [[sales-discovery-coach]] 在发现阶段技术深度参与度上存在张力——前者主张售前主导技术发现，后者主张销售发现以业务语言建立信任；与 [[sales-deal-strategist]] 共享竞争定位和 Winning/Battling/Losing 三区分析，但前者专注于技术评估层，后者覆盖全周期交易策略。属 The Agency Sales 团队完整销售闭环中的技术评估支柱。
|
||||
|
||||
### The Agency — Specialized 部门
|
||||
|
||||
**[[specialized-civil-engineer]]**（Civil Engineer）：全球设计标准覆盖的结构与土木工程专家 Agent——专注于安全、经济、可建造的结构设计，驾驭 Eurocode（EN 1990–1999 + 各国 National Annex）、ACI 318（LRFD/SD）、AISC 360、ASCE 7、GB、IS、AIJ 等全球主流建筑规范体系。核心能力：**ULS+SLS 双重验证**（承载力极限状态与正常使用极限状态必须同时满足方为合格）+ **多标准冲突处理**（IBC+Eurocode 混用时识别冲突→文档记录→保守优先→设计依据报告）+ **岩土工程**（地勘报告解读、承载力/沉降分析、挡土结构、边坡稳定）。计算交付物包括：钢梁 AISC 360 LRFD 计算包（截面选型→抗弯验算→挠度检查）、RC 梁 Eurocode EN 1992-1-1 计算包（K 法配筋设计→抗剪验算）、岩土地基 Terzaghi 承载力分析（含 EN 1997 DA1 验证）。六阶段工作流：项目范围→初步设计→详细计算→建造文档→规范合规→施工支持。属 The Agency Specialized 部门的基础设施工程方向，与 [[specialized-developer-advocate]]（开发者关系）同属 Specialized 专业 Agent 系列，与 [[specialized-workflow-architect]]（工作流架构）存在依赖关系。
|
||||
|
||||
## Conflict Areas
|
||||
|
||||
1. **Kanban vs Event Sourcing**: Kanban emphasizes visual team collaboration; Event Sourcing emphasizes auto-tracking and context preservation. **[[Project State Management]]**（事件驱动看板替代方案）vs 传统 PM 工具。核心差异：手动拖拽 vs 自然语言输入；静态快照 vs 全历史保留；无上下文 vs 完整决策链。**[[Event Sourcing]]** 在此上下文中指将项目变更存储为事件序列，每次 progress/blocker/decision/pivot 均持久化，保留完整决策上下文。
|
||||
|
||||
55
wiki/sources/project-management-experiment-tracker.md
Normal file
55
wiki/sources/project-management-experiment-tracker.md
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "Experiment Tracker Agent Personality"
|
||||
type: source
|
||||
tags: ["agent", "project-management", "experimentation", "a-b-testing"]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/project-management/project-management-experiment-tracker.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI Agent 角色定义——Experiment Tracker（实验追踪专家），专注于实验设计、执行追踪与数据驱动决策的专家级项目经理
|
||||
- 问题域：产品迭代中的实验管理缺乏系统性、数据驱动决策缺乏科学严谨性、实验成功率低
|
||||
- 方法/机制：通过 A/B 测试、多变量实验、假设验证、Portfolio Management、统计功效分析实现科学化实验管理
|
||||
- 结论/价值：为 AI Agent 系统提供标准化的实验追踪角色定义，支撑数据驱动的产品迭代决策
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Experiment Tracker 通过严格的统计方法论和实验设计，系统管理 A/B 测试、功能实验和假设验证，确保 95% 置信度的数据驱动决策可靠性
|
||||
- Experiment Tracker 通过 Portfolio Management 协调多个并发实验，优化资源配置，每季度交付 15+ 实验，实验成功率达 70%
|
||||
- Experiment Tracker 提供实验设计文档模板和实验结果交付模板，标准化实验全生命周期管理流程
|
||||
- Experiment Tracker 通过多臂老虎机（Multi-armed Bandits）、贝叶斯分析、因果推断等高级统计技术，实现连续学习和最优实验决策
|
||||
- Experiment Tracker 通过机器学习模型 A/B 测试、个性化实验设计和预测建模，实现高级数据科学集成
|
||||
|
||||
## Key Quotes
|
||||
> "Always calculate proper sample sizes before experiment launch" — 确保统计可靠性的基础要求
|
||||
> "95% of experiments reach statistical significance with proper sample sizes" — 实验成功标准
|
||||
> "Experiment velocity exceeds 15 experiments per quarter" — 实验吞吐量目标
|
||||
> "Zero experiment-related production incidents or user experience degradation" — 安全底线
|
||||
|
||||
## Key Concepts
|
||||
- [[A/B-Testing]]：对照实验，通过控制组与变体组的比较验证假设
|
||||
- [[Statistical-Significance]]：统计显著性，95% 置信度为默认要求
|
||||
- [[Power-Analysis]]：统计功效分析，确保实验有足够样本量
|
||||
- [[Hypothesis-Validation]]：假设验证，通过实验数据验证产品假设
|
||||
- [[Experiment-Portfolio-Management]]：实验组合管理，优化多实验资源分配与优先级
|
||||
- [[Multi-Armed-Bandits]]：多臂老虎机，高级实验设计实现动态流量分配
|
||||
- [[Bayesian-Analysis]]：贝叶斯分析方法，支持连续学习与实时决策
|
||||
- [[Causal-Inference]]：因果推断技术，理解实验的真正效果
|
||||
|
||||
## Key Entities
|
||||
- [[Project-Management-Experiment-Tracker]]：实验追踪专家 Agent 本身
|
||||
- [[Project-Management-Studio-Producer]]：受益于 Experiment Tracker 的实验数据，协调内容制作迭代
|
||||
- [[LaunchDarkly]]：Feature Flag 平台，支持 Experiment Tracker 的渐进放量与 A/B 测试
|
||||
|
||||
## Connections
|
||||
- [[Project-Management-Studio-Operations]] ← coordinates_with ← [[Project-Management-Experiment-Tracker]]
|
||||
- [[Project-Management-Studio-Producer]] ← depends_on ← [[Project-Management-Experiment-Tracker]]
|
||||
- [[Project-Management-Jira-Workflow-Steward]] ← integrates_with ← [[Project-Management-Experiment-Tracker]]
|
||||
- [[Project-Management-Project-Shepherd]] ← leverages ← [[Project-Management-Experiment-Tracker]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Project-Management-Studio-Operations]] 潜在冲突：Studio Operations 强调内容制作流程的确定性，Experiment Tracker 依赖实验数据驱动，存在节奏冲突（快速实验 vs 稳定制作）
|
||||
- 冲突点：决策依据（直觉/经验 vs 数据）
|
||||
- 当前观点：数据驱动决策优先，实验验证后再规模化
|
||||
- 对方观点：内容制作需保持节奏稳定，不能因等待实验结果而停滞
|
||||
63
wiki/sources/project-management-jira-workflow-steward.md
Normal file
63
wiki/sources/project-management-jira-workflow-steward.md
Normal file
@@ -0,0 +1,63 @@
|
||||
---
|
||||
title: "Jira Workflow Steward Agent Personality"
|
||||
type: source
|
||||
tags: ["project-management", "jira", "git-workflow", "delivery-traceability", "agent-personality"]
|
||||
date: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/project-management/project-management-jira-workflow-steward.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Jira Workflow Steward——软件交付可追溯性管理 Agent，通过 Jira-Git 全链路绑定，确保每一次代码变更都能从 Jira 任务追踪到分支、提交、PR 直至关线发布
|
||||
- 问题域：团队代码交付过程中分支命名混乱、提交信息不规范、PR 缺乏 ticket 上下文、发布链路不可审计等交付治理难题
|
||||
- 方法/机制：Jira Gate（Jira ID 强制前置检查）→ 分支策略（feature/bugfix/hotfix/release 分流）→ Gitmoji 规范提交 → PR 模板 → Commit Hook 自动化验证
|
||||
- 结论/价值：使代码交付可审查、可回滚、可审计，将 Jira-linked commits 定位为质量工具而非合规打勾
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Jira Task ID 是所有 Git 工作流输出的前提：分支名、提交信息、PR 标题均必须包含有效 Jira ID，无 ID 则停止工作流
|
||||
- 分支策略需遵循仓库意图：feature/bugfix 从 develop 分支；hotfix 从 main 分支；release 用于发布准备，各路径互不混淆
|
||||
- 提交信息遵循 `<Gitmoji> JIRA-ID: 简短描述` 格式，选择 Gitmoji 需参照官方 catalog（gitmoji.dev / carloscuesta/gitmoji）
|
||||
- PR 是 main、release/*、大型重构和关键基础设施变更的强制门控，任何合并均需经过 review
|
||||
- 秘密/凭证/客户数据严禁出现在分支名、提交信息、PR 标题或描述中
|
||||
- Jira-linked commits 的价值在于提升 review 上下文、代码结构、发布说明质量和事故溯源能力，而非仅为合规
|
||||
|
||||
## Key Quotes
|
||||
> "If a change cannot be traced from Jira to branch to commit to pull request to release, you treat the workflow as incomplete." — 核心原则：可追溯性即质量
|
||||
> "Jira-linked commits as a quality tool, not just a compliance checkbox" — 提交绑定 Jira 的定位重塑：质量工具而非合规工具
|
||||
> "Protect repository clarity: the commit message should say what changed, not that you 'fixed stuff'." — 提交信息质量标准
|
||||
|
||||
## Key Concepts
|
||||
- [[Jira-Git-Traceability]]：通过 Jira ID 将 Jira 任务、分支、提交、PR、发布五个环节串联为完整可追溯链路的实践
|
||||
- [[Atomic-Commit]]：每次提交仅包含一个逻辑变更，易于审查、回滚和溯源的提交粒度原则
|
||||
- [[Branch-Strategy]]：基于功能/缺陷/热修复/发布类型的分支分层管理模型（feature/bugfix/hotfix/release）
|
||||
- [[Gitmoji-Commit]]：使用标准化 Emoji 前缀标注提交类型的提交规范（✨ 新功能、🐛 缺陷修复、♻️ 重构等）
|
||||
- [[Jira-Gate]]：强制要求所有 Git 工作流输出必须携带有效 Jira Task ID 的门控机制，无 ID 则停止工作流
|
||||
- [[Pull-Request-Governance]]：通过 PR 模板、安全审查、风险记录保护分支合并质量的工作流规范
|
||||
- [[Delivery-Traceability]]：从需求到代码发布全链路的可重建、可审计交付记录体系
|
||||
|
||||
## Key Entities
|
||||
- [[Gitmoji]]：标准化 Emoji 提交规范工具（来源：gitmoji.dev / carloscuesta/gitmoji）；Jira Workflow Steward 使用其作为提交类型的视觉标签
|
||||
- [[GitHub]]：PR 托管和分支策略执行平台；PR 模板和安全门控在此实现
|
||||
- [[Project-Management-Project-Shepherd]]：同为项目管理领域的 Agent；Project Shepherd 负责整体项目协调，Jira Workflow Steward 专注交付可追溯性，两者互补
|
||||
- [[Project-Management-Studio-Operations]]：同为 The Agency 项目管理层级中的 Agent；Studio Operations 负责运营流程，Jira Workflow Steward 负责技术交付链路
|
||||
|
||||
## Connections
|
||||
- [[Jira-Gate]] ← 是 [[Delivery-Traceability]] 的第一步门控
|
||||
- [[Branch-Strategy]] ← 支撑 [[Jira-Git-Traceability]] 的分支层
|
||||
- [[Atomic-Commit]] ← 支撑 [[Jira-Git-Traceability]] 的提交层
|
||||
- [[Pull-Request-Governance]] ← 支撑 [[Jira-Git-Traceability]] 的审查层
|
||||
- [[Gitmoji-Commit]] ← 提供 [[Atomic-Commit]] 的标准化视觉表达
|
||||
- [[Project-Management-Project-Shepherd]] ← 上游协调者，提供 Jira 任务；[[Jira-Workflow-Steward]] 负责将任务转化为可追溯代码交付
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Project-Management-Project-Shepherd]] 在职责边界上存在互补但需协调的张力：
|
||||
- 冲突点：Project Shepherd 生成 Jira 任务，Jira Workflow Steward 要求任务必须存在才能工作——两者均强调任务先行，但无主动对接机制
|
||||
- 当前观点：Steward 严格 gate，要求任务 ID 前置；若缺失则停止工作流并请求补充
|
||||
- 对方观点：Project Shepherd 可能期望 Agent 能自动创建或推断 Jira 任务 ID
|
||||
- 建议协调：在 Project Shepherd 的工作流中增加 Jira 任务预创建步骤，确保交接给 Steward 时 ID 已就绪
|
||||
- 与 [[Project-Management-Studio-Producer]] 在交付粒度上存在层级差异：
|
||||
- Studio Producer 关注组合级（Portfolio）ROI 和战略优先级，Jira Workflow Steward 关注原子级代码提交
|
||||
- 当前观点：Steward 坚持每个 commit 对应一个 Jira ID，保持最小粒度可追溯
|
||||
- 对方观点：Producer 可能在聚合分析时需要更高粒度的任务层级（Epic/Story vs Task）
|
||||
- 无直接冲突，属不同抽象层级的关注点差异
|
||||
53
wiki/sources/project-management-project-shepherd.md
Normal file
53
wiki/sources/project-management-project-shepherd.md
Normal file
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: "Project Shepherd Agent Personality"
|
||||
type: source
|
||||
tags: [project-management, agent, cross-functional, stakeholder-management, risk-mitigation]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/project-management/project-management-project-shepherd.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI Agent 项目管理人格——Project Shepherd，模拟跨职能项目协调专家，专注文档进度、对齐干系人、管理风险
|
||||
- 问题域：复杂项目的全生命周期管理，包括多团队/多部门协调、时间线规划、资源分配、干系人沟通
|
||||
- 方法/机制：四阶段工作流（项目启动→团队组建→执行监控→质量交付）、Project Charter 模板、Status Report 模板、风险缓解框架、干系人沟通策略
|
||||
- 结论/价值：提供一套完整的 AI Agent 项目管理人格定义，可直接用于 Multi-Agent 系统中的项目协调角色
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Project Shepherd Agent 通过四阶段工作流（启动→团队组建→执行→交付）驱动复杂项目按时、按范围、按预算完成
|
||||
- 通过 disciplined change control 限制范围蔓延，目标将范围蔓延控制在 10% 以下
|
||||
- 通过 proactive risk mitigation，目标实现 90% 的已识别风险在影响项目结果前被成功缓解
|
||||
- 通过透明沟通和诚实汇报维持干系人信任，即使在传递负面消息时也保持透明
|
||||
- 95% 项目按时交付、95% 干系人满意度 4.5/5 是核心成功指标
|
||||
|
||||
## Key Quotes
|
||||
> "Never commit to unrealistic timelines to please stakeholders" — 绝不为了取悦干系人而承诺不现实的工期
|
||||
> "Provide honest, transparent reporting even when delivering difficult news" — 即便传递困难消息也提供诚实透明的汇报
|
||||
> "Escalate issues promptly with recommended solutions, not just problems" — 问题升级时必须附上建议的解决方案，而非仅提出问题
|
||||
|
||||
## Key Concepts
|
||||
- [[CrossFunctionalProjectCoordination]]：跨职能项目协调——协调多个团队和部门完成复杂项目的能力
|
||||
- [[StakeholderAlignment]]：干系人对齐——通过沟通策略和透明汇报维持所有项目参与者的期望一致
|
||||
- [[RiskMitigationPlanning]]：风险缓解规划——在风险影响项目结果前主动识别、评估并制定应对策略
|
||||
- [[ChangeControl]]：变更控制——通过纪律化的范围管理控制项目范围蔓延（目标 < 10%）
|
||||
- [[ProjectCharter]]：项目章程——定义项目目标、范围、成功标准和治理结构的初始文档
|
||||
- [[WorkBreakdownStructure]]：工作分解结构（WBS）——将大型项目拆解为可管理的任务和依赖关系
|
||||
- [[CriticalPathAnalysis]]：关键路径分析——识别项目中最长的依赖链，确保关键里程碑按时完成
|
||||
- [[MatrixOrganization]]：矩阵式组织——在跨多条汇报线的组织结构中协调资源的能力
|
||||
|
||||
## Key Entities
|
||||
- [[ProjectShepherd]]：AI Agent 项目管理人格定义，专职跨职能项目协调、时间线管理和干系人对齐
|
||||
- [[ProjectCharter]]（模板）：定义项目概览、干系人分析、资源需求和风险评估的文档模板
|
||||
- [[ProjectStatusReport]]（模板）：包含执行摘要、进度更新、问题风险和干系人行动的定期报告模板
|
||||
- [[ExecutiveSponsor]]：执行发起人——拥有决策权威和升级终点的干系人角色
|
||||
- [[CrossFunctionalProjectTeam]]：跨职能项目团队——由多个技能领域成员组成的核心项目团队
|
||||
|
||||
## Connections
|
||||
- [[ProjectManagementStudioOperations]] ← extends ← [[ProjectShepherd]] — Studio Operations 是项目管理在创意制作场景的延伸
|
||||
- [[ProjectManagementSenior]] ← related_to ← [[ProjectShepherd]] — 两者都是项目管理者，但 Senior PM 侧重高级战略，Shepherd 侧重跨职能协调执行
|
||||
- [[AutonomousProjectManagement]] ← depends_on ← [[ProjectShepherd]] — 自主项目管理依赖 Shepherd 提供的工作流和模板框架
|
||||
- [[ProjectStateManagement]] ← related_to ← [[ProjectShepherd]] — 两者都涉及项目状态跟踪，但 State Management 偏向事件驱动替代看板的方法论
|
||||
|
||||
## Contradictions
|
||||
- 无明显内容冲突。本文档与 [[ProjectManagementSenior]] 和 [[ProjectManagementStudioOperations]] 在项目管理层面上互补而非冲突，各有侧重领域。
|
||||
54
wiki/sources/project-management-studio-operations.md
Normal file
54
wiki/sources/project-management-studio-operations.md
Normal file
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: "Studio Operations Agent Personality"
|
||||
type: source
|
||||
tags: ["project-management", "agency-agents", "operations", "efficiency"]
|
||||
date: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/project-management/project-management-studio-operations.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Studio Operations 智能体角色定义——一个专注于日常工作室运营效率、流程优化和资源协调的专业运营管理者
|
||||
- 问题域：工作室运营管理、流程标准化、资源调度、质量控制、持续改进
|
||||
- 方法/机制：通过标准操作程序（SOP）模板、运营效率报告模板、四步工作流（评估→协调→实施→监控）实现 95% 运营效率目标
|
||||
- 结论/价值：提供一套完整的工作室运营管理框架，涵盖流程优化、资源管理、团队支持、数字化转型和战略运营管理
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 通过标准操作程序和流程文档化，可实现 95% 运营效率（附带主动系统维护）
|
||||
- 流程优化可每周为所有团队节省 40 小时生产力时间
|
||||
- 新调度系统实施可将会议冲突减少 85%
|
||||
- 全面的供应商管理可降低运营成本 15%
|
||||
- 主动监控和维护可保持 99.5% 系统正常运行时间
|
||||
- 运营支持请求响应时间少于 2 小时
|
||||
- 团队满意度评分达到 4.5/5
|
||||
|
||||
## Key Quotes
|
||||
> "You are **Studio Operations**, an expert operations manager who specializes in day-to-day studio efficiency, process optimization, and resource coordination." — 角色定义核心描述
|
||||
> "Ensure 95% operational efficiency with proactive system maintenance" — 默认运营效率要求
|
||||
> "Implemented new scheduling system reducing meeting conflicts by 85%" — 服务导向的运营成果示例
|
||||
> "99.5% system uptime maintained with proactive monitoring and maintenance" — 可靠性导向的运营成果示例
|
||||
|
||||
## Key Concepts
|
||||
- [[Standard Operating Procedure]]：标准操作程序模板，包含概述、前提条件、分步程序、质量控制、文档记录五个部分
|
||||
- [[Operational Efficiency]]：运营效率，目标为 95%，通过主动系统维护实现
|
||||
- [[Resource Coordination]]：跨所有工作室活动的资源分配和调度协调
|
||||
- [[Continuous Improvement]]：持续改进文化，通过分析运营指标和实施流程自动化实现
|
||||
- [[Digital Transformation]]：数字化转型，使用现代工作流工具、集成平台和 AI 驱动的运营辅助
|
||||
- [[Vendor Management]]：供应商关系管理和成本优化
|
||||
|
||||
## Key Entities
|
||||
- [[The Agency]]：工作室所属组织，Studio Operations 智能体为其提供全面运营支持
|
||||
|
||||
## Connections
|
||||
- [[Project Management Senior]] ← related_to ← [[Studio Operations]]
|
||||
- [[Project Management Studio Producer]] ← related_to ← [[Studio Operations]]
|
||||
- [[Project Management Jira Workflow Steward]] ← related_to ← [[Studio Operations]]
|
||||
- [[Project Management Project Shepherd]] ← depends_on ← [[Studio Operations]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Project Management Senior]] 冲突：
|
||||
- 冲突点：战略规划与日常运营的优先级
|
||||
- 当前观点（Studio Operations）：强调流程优化和运营效率的日常执行
|
||||
- 对方观点（Senior PM）：强调战略规划和项目组合管理
|
||||
- 协调方式：Studio Operations 负责执行层面，Senior PM 负责战略层面，两者互补
|
||||
52
wiki/sources/project-management-studio-producer.md
Normal file
52
wiki/sources/project-management-studio-producer.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "Studio Producer Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/project-management/project-management-studio-producer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- **核心主题**：Studio Producer Agent——专注于高管级别创意与项目管理的高级战略领导者 Agent，属于 Agency 项目管理部门。核心职责：战略组合管理、创意愿景与商业目标对齐、跨职能团队协调。
|
||||
- **问题域**：多项目组合管理、资源分配优化、高管级利益相关者沟通、风险与财务管控、团队绩效管理。
|
||||
- **方法/机制**：Strategic Portfolio Plan 模板（四层项目分级）、Strategic Portfolio Review 模板（季度复盘）、四阶段工作流（战略规划→项目编排→领导力发展→绩效优化）、ROI + 按时交付双指标驱动。
|
||||
- **结论/价值**：AI Agent 角色定位为高管级战略领导者，要求 25% 组合 ROI + 95% 按时交付率，面向需要复杂创意项目管理的组织。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- **Studio Producer** 通过战略组合规划（Strategic Portfolio Plan）将创意愿景与商业目标对齐，在项目分级（Tier 1/2 + Innovation Pipeline）中平衡风险与创新
|
||||
- **Portfolio ROI ≥ 25% + 95% on-time delivery** 是该角色的核心成功指标，要求同时管理财务纪律与创意卓越
|
||||
- **四阶段工作流**（战略规划→项目编排→领导力发展→绩效优化）构成该 Agent 的标准运营框架
|
||||
- **利益相关者管理**是该角色的核心竞争力，涉及高管沟通、期望设定与战略投资获取
|
||||
- **团队绩效与保留率**是该 Agent 的间接成功指标，反映领导力发展的长期效果
|
||||
|
||||
## Key Quotes
|
||||
> "Portfolio ROI consistently exceeds 25% with balanced risk across strategic initiatives" — 核心成功指标定义
|
||||
> "Our Q3 portfolio delivered 35% ROI while establishing market leadership in emerging AI applications" — 沟通风格示例：战略性启发
|
||||
> "Board presentation highlights our competitive advantages and 3-year strategic positioning" — 执行影响思维示例
|
||||
> "Creative excellence drove $5M revenue increase and strengthened our premium brand positioning" — 业务价值导向示例
|
||||
|
||||
## Key Concepts
|
||||
- [[Strategic-Portfolio-Management]]：通过分级项目组合（Tier 1/2 + Innovation Pipeline）实现资源最优配置与商业目标对齐
|
||||
- [[Resource-Allocation]]：跨创意/技术资源的计划与分配，平衡短期交付与长期能力建设
|
||||
- [[Stakeholder-Alignment]]：高管级利益相关者关系管理与战略沟通，确保创意愿景与商业目标一致
|
||||
- [[Portfolio-ROI]]：组合层面的投资回报率优化，Studio Producer 要求 ≥ 25% ROI
|
||||
- [[Risk-Balancing]]：在创新实验与已验证方法之间管理风险敞口
|
||||
- [[Cross-Functional-Orchestration]]：协调跨职能团队形成与战略对齐，管理复杂相互依赖关系
|
||||
- [[Innovation-Pipeline]]：实验性项目的管理框架，设定学习目标而非短期回报
|
||||
|
||||
## Key Entities
|
||||
- [[Project-Management-Studio-Operations]]：Studio Producer 的运营执行搭档，负责具体项目交付
|
||||
- [[Project-Manager-Senior]]：项目经理的高级版本，更侧重执行层面
|
||||
- [[Project-Management-Project-Shepherd]]：项目看护角色，关注项目生命周期跟进
|
||||
- [[Project-Management-Experiment-Tracker]]：实验跟踪角色，关注迭代与学习
|
||||
|
||||
## Connections
|
||||
- [[Project-Management-Studio-Operations]] ← supports ← [[Project-Management-Studio-Producer]]（战略规划由 Producer 制定，Operations 负责落地执行）
|
||||
- [[Project-Management-Project-Shepherd]] ← coordinates_with ← [[Project-Management-Studio-Producer]]（项目看护与 Producer 的组合管理对齐）
|
||||
- [[Sales-Engineer]] ← interfaces_with ← [[Project-Management-Studio-Producer]]（售前赢单后转交 Producer 编排交付）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Project-Management-Studio-Operations]] 的角色边界：张力存在于战略（Producer）与运营（Operations）之间的权责划分——Producer 偏向高管级战略视角，Operations 偏向执行层；两者需通过定期 Portfolio Review 对齐
|
||||
- 与传统 [[Project-Manager-Senior]] 的管理幅度：张力存在于管理广度——Producer 管理整个组合（Portfolio），而 Senior PM 通常管理单个项目；这是层级差异而非矛盾
|
||||
50
wiki/sources/project-manager-senior.md
Normal file
50
wiki/sources/project-manager-senior.md
Normal file
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: "Senior Project Manager Agent Personality"
|
||||
type: source
|
||||
tags: [agent, project-management, laravel, livewire, fluxui, scope-control]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/project-management/project-manager-senior.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI Agent 项目经理（SeniorProjectManager）的人格定义与任务分解方法论
|
||||
- 问题域：Web 开发项目中需求规格到可执行任务的转化过程，以及如何避免范围蔓延（scope creep）
|
||||
- 方法/机制：读取 site-setup.md 规格文档 → 引用精确需求 → 拆解为 30-60 分钟粒度的任务列表 → 存储到 memory-bank
|
||||
- 结论/价值：提供一套结构化的 AI PM 工作流程，强调务实（realistic scope）、精确引用规格、开发者优先
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- **Agent + 规格文件 + 精确引用 → 任务列表**：通过逐字引用规格文档中的原始需求来创建任务，避免主观添加功能
|
||||
- **Agent + 经验积累 + 模式库 → 持续改进**：从每个项目中学习，构建成功任务拆解的模式库
|
||||
- **Agent + 务实范围 + 基础实现 → 避免失败**：默认基础实现即可接受，优先完成功能而非打磨
|
||||
|
||||
## Key Quotes
|
||||
> "Quote EXACT requirements (don't add luxury/premium features that aren't there)" — 规格引用原则，要求 Agent 不添加规格中未明确的功能
|
||||
> "Each task should be implementable by a developer in 30-60 minutes" — 任务粒度标准，保证任务可执行性
|
||||
> "Don't add 'luxury' or 'premium' requirements unless explicitly in spec" — 务实范围控制，防止范围蔓延
|
||||
> "No background processes in any commands - NEVER append `&`" — 技术约束，Agent 必须遵守的技术红线
|
||||
|
||||
## Key Concepts
|
||||
- [[ScopeCreepPrevention]]：通过精确引用规格、限制基础实现、记录范围决策来防止项目范围蔓延
|
||||
- [[TaskDecomposition]]：将规格拆解为 30-60 分钟粒度的可执行任务，包含验收标准
|
||||
- [[AgenticProjectManagement]]：AI Agent 作为项目经理角色，通过记忆和经验积累持续改进任务创建流程
|
||||
- [[FluxUI]]：Laravel Livewire 生态的前端组件库，PM Agent 需了解其组件属性和约束
|
||||
- [[AcceptanceCriteria]]：每个任务必须包含可测试的验收标准
|
||||
|
||||
## Key Entities
|
||||
- [[ProjectManagementJiraWorkflowSteward]]：同属项目管理体系，另一个专注于 Jira 工作流编排的 Agent
|
||||
- [[ProjectManagementProjectShepherd]]：同属项目管理体系，专注于项目全局把控的 Agent
|
||||
- [[ProjectManagementStudioOperations]]：同属项目管理体系，专注于工作室运营的 Agent
|
||||
|
||||
## Connections
|
||||
- [[ProjectManagementJiraWorkflowSteward]] ← related_to ← [[ProjectManagerSenior]]
|
||||
- [[ProjectManagementProjectShepherd]] ← related_to ← [[ProjectManagerSenior]]
|
||||
- [[ProjectManagementStudioOperations]] ← related_to ← [[ProjectManagerSenior]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[ProjectManagementProjectShepherd]] 可能的冲突：
|
||||
- 冲突点：职责边界 — Project Shepherd 关注项目整体把控，Senior PM 关注任务拆解细节
|
||||
- 当前观点：Senior PM 强调任务粒度控制和精确引用规格，务实处理基础功能
|
||||
- 对方观点：Project Shepherd 可能更关注项目整体节奏和风险，需要更高层次的抽象
|
||||
- 协调建议：Senior PM 产出任务列表供 Project Shepherd 调度，两者形成执行层与规划层的协作关系
|
||||
53
wiki/sources/recruitment-specialist.md
Normal file
53
wiki/sources/recruitment-specialist.md
Normal file
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: "Recruitment Specialist Agent"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/specialized/recruitment-specialist.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：RecruitmentSpecialist 是一个专注于中国人力资源市场的招聘运营与人才获取专家 Agent，覆盖从人才吸引、入职到留任的全周期招聘引擎
|
||||
- 问题域：中国招聘平台运营、JD 优化、简历筛选、面试流程设计、校园招聘、猎头管理、劳动法合规、雇主品牌建设、入职管理、招聘数据分析
|
||||
- 方法/机制：多平台渠道运营（BOSS直聘、拉勾、猎聘、智联、前程无忧、脉脉、LinkedIn）、结构化面试（STAR 框架）、能力模型评估、ATS 系统集成、劳动法合规检查、招聘漏斗数据分析
|
||||
- 结论/价值：帮助企业建立高效、合规、数据驱动的全链路招聘系统，提升招聘ROI、缩短到岗周期、降低试用期流失率
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 通过多平台渠道精细化运营，可实现招聘ROI持续提升，每季度渠道成本趋于下降
|
||||
- 使用STAR行为面试框架和结构化评分卡，可提升面试评估准确性和一致性
|
||||
- 严格遵守中国劳动法（劳动合同法、就业促进法、个人信息保护法）可避免合规风险和赔偿损失
|
||||
- 数据驱动的招聘漏斗分析能识别瓶颈并持续优化各环节转化率
|
||||
- 候选人体验（NPS 80+）与 offer 接受率（85%+）高度相关
|
||||
|
||||
## Key Quotes
|
||||
> "When candidates wait more than 5 days from application to first response, application conversion drops by 40%. We must keep initial response time under 48 hours." — 候选人响应时效对转化率的影响
|
||||
> "Boss Zhipin's cost per resume is one-third of Liepin's, but candidate quality for mid-to-senior roles is lower. I recommend using Boss for junior roles and Liepin for senior ones." — 招聘渠道ROI差异化建议
|
||||
> "If the probation period exceeds the statutory limit, the company must pay compensation based on the completed probation standard. This risk must be avoided." — 试用期合规风险警示
|
||||
|
||||
## Key Concepts
|
||||
- [[RecruitmentFunnelAnalyzer]]：招聘漏斗分析器类，计算各环节转化率、渠道ROI、入职周期
|
||||
- [[STAR Framework]]：行为面试框架（Situation-Task-Action-Result），用于评估候选人具体行为
|
||||
- [[Structured Interview]]：结构化面试，使用标准化评分卡确保面试一致性和评估准确性
|
||||
- [[China Labor Law Compliance]]：中国劳动法合规，包括劳动合同法、试用期规定、五险一金、竞业限制、N+1 补偿等
|
||||
- [[Employer Brand Building]]：雇主品牌建设，通过短视频、内容营销、平台口碑管理提升对人才的吸引力
|
||||
- [[Onboarding SOP]]：标准化入职流程，从入职前7天到第一个月的完整 checklist
|
||||
|
||||
## Key Entities
|
||||
- [[Boss Zhipin]]（BOSS直聘）：中国领先的直聊招聘平台，简历成本低，适合初级岗位
|
||||
- [[Lagou]]（拉勾网）：专注互联网/科技岗位的招聘平台，技能标签匹配算法
|
||||
- [[Liepin]]（猎聘网）：中高端猎头导向平台，适合资深岗位
|
||||
- [[Beisen]]（北森）：领先的HR SaaS，ATS 系统用于招聘流程管理
|
||||
- [[Moka]]（Moka智能招聘）：智能化 ATS 系统
|
||||
- [[Feishu Recruiting]]（飞书招聘）：字节跳动 Lark 的 HR 模块
|
||||
- [[STAR Method]]：行为面试评估方法论
|
||||
|
||||
## Connections
|
||||
- [[Specialized Civil Engineer Agent]] ← 同一 Agent 体系下的专业 Agent
|
||||
- [[Sales Engineer Agent]] ← 同属专业 Agent 系列
|
||||
- [[HR Onboarding]] ← 入职管理是该 Agent 的核心功能模块
|
||||
- [[RecruitmentFunnelAnalyzer]] ← 内置于该 Agent 的数据分析工具
|
||||
|
||||
## Contradictions
|
||||
- 暂无发现与现有 Wiki 页面的冲突内容
|
||||
52
wiki/sources/specialized-civil-engineer.md
Normal file
52
wiki/sources/specialized-civil-engineer.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "Specialized Civil Engineer Agent"
|
||||
type: source
|
||||
tags: ["agent", "civil-engineering", "structural-design", "geotechnical", "building-codes"]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/specialized/specialized-civil-engineer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：面向 AI Agent 的土木与结构工程专家角色定义，涵盖全球设计标准体系、结构分析与岩土设计能力、建造文档合规全流程
|
||||
- 问题域：AI Agent 在建筑结构工程领域的专业化角色设计，涉及多国规范体系（Eurocode、ACI、AISC、ASCE、GB、IS、AIJ 等）的统一知识表示与任务执行框架
|
||||
- 方法/机制：通过结构化角色定义（身份记忆→核心使命→规范规则→交付物→工作流→高级能力）构建可执行的结构工程 Agent；提供钢梁/RC 梁/岩土计算示例作为能力基准
|
||||
- 结论/价值：产出安全、经济、可建造的结构设计，同时驾驭多管辖区域并发规范、多标准冲突解析、全生命周期碳评估等高级任务
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- AI Agent 可通过规范引用驱动（"Per EN 1992-1-1 clause 6.2.3..."）的方式执行可验证的结构计算包
|
||||
- 多标准项目（IBC+Eurocode 混用等）中，Agent 可通过规范冲突识别→文档记录→保守优先→设计依据报告的流程提供可辩护的解决方案
|
||||
- 结构设计必须同时验证强度极限状态（ULS）和正常使用极限状态（SLS/挠度/振动），两者均满足方为合格
|
||||
- 岩土参数不得未经地勘报告或明确假设即行假定；沉降分析对差异沉降敏感结构为必做项
|
||||
|
||||
## Key Quotes
|
||||
> "Always check **both** strength (ULS) and serviceability (SLS) limit states" — 强度与正常使用双重验证原则
|
||||
> "Default to the more conservative requirement unless AHJ rules otherwise" — 多标准冲突时的默认处理策略
|
||||
> "Never assume soil parameters without a ground investigation report or clear stated assumptions" — 岩土参数假设的铁律
|
||||
> "Calculation packages must be self-contained: inputs, references, calculations, results" — 计算包自包含性要求
|
||||
|
||||
## Key Concepts
|
||||
- [[ULS]]（极限状态设计/Strength Limit State）：结构承载力极限状态，对应 Eurocode EN 1990 中的 ULS、ACI 318 LRFD
|
||||
- [[SLS]]（正常使用极限状态/Serviceability Limit State）：挠度、振动、裂缝控制，对应 EN 1990 SLS、ACI 318 serviceability provisions
|
||||
- [[National Annex]]（国家附录）：Eurocode 各成员国对 NDPs（国家确定参数）的本地化修订，是规范冲突的主要来源
|
||||
- [[AHJ]]（Authority Having Jurisdiction）：主管当局，拥有最终解释权，多标准项目需向 AHJ 确认
|
||||
- [[Basis of Design]]（设计依据）：记录所有关键假设、规范版本选择、荷载组合、设计决策的正式文件
|
||||
- [[Ductility Class]]（延性等级）：Eurocode EN 1998 的 DCL/DCM/DCH，地震设计中的结构延性要求分级
|
||||
- [[LRFD]]（荷载抗力系数设计）：美国 ACI/AISC 体系采用的设计方法，与 Eurocode 的部分系数法（EN 1990 DA1/DA2/DA3）思路相近但系数不同
|
||||
- [[BIM Coordination]]（BIM 协调）：结构模型导出 IFC 4.x、碰撞检测、穿楼板开孔、钢筋保护层协调等
|
||||
|
||||
## Key Entities
|
||||
- [[Eurocode]]：欧洲规范体系 EN 1990–1999，覆盖结构设计荷载、混凝土/钢/木/砌体结构、岩土、抗震等九大领域，附各国 National Annex
|
||||
- [[AISC 360]]：美国钢结构设计规范（LRFD 与 ASD 双轨），含构件设计、连接设计、冷弯型钢结构
|
||||
- [[ACI 318]]：美国钢筋混凝土设计规范，LRFD/SD 方法，含特殊抗弯框架（SMF）抗震细部要求
|
||||
- [[ASCE 7]]：美国建筑及其他结构最小设计荷载规范，涵盖重力荷载、风荷载、地震荷载、冰雪荷载等第 2–31 章
|
||||
- [[EN 1997]]：Eurocode 岩土设计规范，含浅基础、深基础、挡土结构、土坡稳定的体系化设计方法
|
||||
- [[AIJ]]（Architectural Institute of Japan）：日本建筑学会规范，高抗震延性要求、响应谱法抗震设计指南
|
||||
|
||||
## Connections
|
||||
- [[specialized-developer-advocate]] ← shares → [[specialized-mcp-builder]]（同属 specialized 专业 Agent 系列）
|
||||
- [[specialized-civil-engineer]] ← implements → [[specialized-workflow-architect]]（专业 Agent 依赖工作流架构）
|
||||
|
||||
## Contradictions
|
||||
- 暂无已知冲突。该 Agent 覆盖全球多套独立规范体系，各标准间差异已明确标注（如 Eurocode vs ACI vs GB 的荷载分项系数不可混用），符合预期。
|
||||
68
wiki/sources/visionos-spatial-engineer.md
Normal file
68
wiki/sources/visionos-spatial-engineer.md
Normal file
@@ -0,0 +1,68 @@
|
||||
---
|
||||
title: "visionOS Spatial Engineer"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/spatial-computing/visionos-spatial-engineer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：visionOS 原生空间计算 Agent，专注于 volumetric 界面与 Liquid Glass 设计系统实现
|
||||
- 问题域：Apple visionOS 26 平台上的空间应用开发，缺乏统一的设计与工程实践框架
|
||||
- 方法/机制：基于 SwiftUI/RealityKit 技术栈，通过 Liquid Glass Design System 驱动透明材质渲染，结合 WindowGroup 多窗口架构和 SwiftUI Volumetric API 实现 3D 内容集成
|
||||
- 结论/价值：为 The Agency Spatial Computing 部门提供 visionOS 原生开发能力，与 [[macos-spatial-metal-engineer]]（Metal 渲染侧）和 [[xr-immersive-developer]]（WebXR 浏览器侧）共同构成 Apple 空间计算全栈能力
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Apple 的 Liquid Glass Design System 通过自适应透明材质，在 light/dark 环境和周围内容变化时动态调整视觉表现
|
||||
- Spatial Widgets 可吸附于墙面和桌面，持久化放置于 3D 空间中，无需应用前台运行
|
||||
- SwiftUI Volumetric API 支持 3D 内容集成、volume 内 transient content 和 breakthrough UI 元素
|
||||
- RealityKit-SwiftUI 集成通过 Observable entities、直接手势处理和 ViewAttachmentComponent 实现声明式 3D 开发
|
||||
- Multi-Window Architecture 通过 WindowGroup 管理空间应用的玻璃背景效果和单实例窗口
|
||||
- GPU 高效渲染是多个玻璃窗口和 3D 内容同时展示的性能保障
|
||||
|
||||
## Key Quotes
|
||||
> "Focuses on leveraging visionOS 26's spatial computing capabilities to create immersive, performant applications that follow Apple's Liquid Glass design principles." — Agent personality description
|
||||
|
||||
## Key Concepts
|
||||
- [[Liquid Glass Design System]]：Apple visionOS 26 的核心视觉设计语言，通过透明材质实现深度感知和空间沉浸感
|
||||
- [[Spatial Widgets]]：可吸附于 3D 空间（墙面/桌面）并持久化放置的小组件，支持跨应用使用
|
||||
- [[SwiftUI Volumetric APIs]]：visionOS 26 新增的 3D 内容渲染 API 集，支持 volumetric 场景和 breakthrough UI
|
||||
- [[RealityKit-SwiftUI Integration]]：RealityKit 实体系统与 SwiftUI 声明式语法的深度集成模式
|
||||
- [[Glass Background Effects]]：glassBackgroundEffect modifier 实现窗口和控件的毛玻璃透明效果
|
||||
- [[Volumetric Presentations]]：空间展示模式，支持 single-instance 窗口和 volume 内的临时内容
|
||||
- [[Spatial Layouts]]：3D 空间定位、深度管理和空间关系处理
|
||||
- [[Multi-Window Architecture]]：基于 WindowGroup 的空间应用多窗口管理模式
|
||||
|
||||
## Key Entities
|
||||
- [[Apple]]：visionOS/SwiftUI/RealityKit/ARKit 框架的缔造者，Liquid Glass Design System 的设计者
|
||||
- [[visionOS]]：Apple 空间计算操作系统，本 Agent 的核心目标平台（visionOS 26+）
|
||||
- [[SwiftUI]]：Apple 声明式 UI 框架，本 Agent 的主要开发语言
|
||||
- [[RealityKit]]：Apple 原生 3D 渲染引擎，与 SwiftUI 深度集成
|
||||
- [[ARKit]]：Apple 增强现实框架，本 Agent 的空间感知能力来源
|
||||
- [[Metal]]：Apple GPU 渲染 API，支撑 Liquid Glass 和 3D 内容的高性能渲染
|
||||
- [[XR-Interface-Architect]]：Spatial Computing 部门 UX/UI 设计专家，与本 Agent 协同构建空间界面
|
||||
- [[macOS-Spatial-Metal-Engineer]]：Apple 平台 Metal 渲染侧专家，与本 Agent 协同构成 Apple 空间计算全栈
|
||||
- [[Terminal-Integration-Specialist]]：Swift 终端仿真专家，本 Agent 依赖其提供命令行交互能力
|
||||
- [[XR-Immersive-Developer]]：同部门 WebXR 开发专家
|
||||
- [[XR-Cockpit-Interaction-Specialist]]：同部门座舱交互专家
|
||||
|
||||
## Connections
|
||||
- [[XR-Immersive-Developer]] ← related_to ← [[visionos-spatial-engineer]]：两者同属 Spatial Computing 部门，前者专注浏览器端 WebXR，后者专注 Apple 原生 visionOS
|
||||
- [[macOS-Spatial-Metal-Engineer]] ← related_to ← [[visionos-spatial-engineer]]：前者专注 Metal 渲染管线，后者专注 SwiftUI/RealityKit 原生应用；两者协同构成完整的 Apple 空间计算平台能力
|
||||
- [[XR-Interface-Architect]] ← supports ← [[visionos-spatial-engineer]]：前者提供 UX/UI 设计框架，本 Agent 负责技术实现
|
||||
- [[Terminal-Integration-Specialist]] ← supports ← [[visionos-spatial-engineer]]：前者提供 Swift 终端仿真集成能力
|
||||
|
||||
## Contradictions
|
||||
- 与 [[XR-Immersive-Developer]] 在平台选择上的差异：
|
||||
- 冲突点：前者基于 WebXR（浏览器端，跨平台），后者基于 visionOS 原生（Apple 独占）
|
||||
- 当前观点：visionOS Spatial Engineer 专注 Apple 原生平台，追求最优性能和平台特性
|
||||
- 对方观点：XR Immersive Developer 优先跨平台兼容性，通过 A-Frame/Three.js 实现浏览器端部署
|
||||
- 协调：两者面向不同场景，前者服务 visionOS 高端沉浸体验，后者服务广泛的 WebXR 设备覆盖
|
||||
|
||||
- 与 [[macOS-Spatial-Metal-Engineer]] 在技术栈选择上的差异：
|
||||
- 冲突点：前者侧重 SwiftUI/RealityKit 声明式开发，后者侧重 Metal/SceneKit 底层渲染
|
||||
- 当前观点：visionOS Spatial Engineer 优先 SwiftUI 的声明式效率和 Apple 官方推荐模式
|
||||
- 对方观点：macOS Spatial/Metal Engineer 认为 Metal 渲染管线对于大规模 3D 数据可视化更可控
|
||||
- 协调：两者在同一问题域互补——前者处理 UI/UX 层应用开发，后者处理 GPU 密集型数据渲染
|
||||
Reference in New Issue
Block a user