Knowledge业务知识
工作中沉淀下来的上下文：会议记录、需求解读、政策、复盘。它会持续修改，并作为 AI 上下文使用。
- 作为 AI 上下文使用
- 按关系相连
- 持续更新
ApexStack/Product/Project Alpha
搜索⌘K
JHSYMK
Project Alpha
In progressSprint 12概览任务时间线文档成员
进度68%
未完成任务24
本周到期6
文档38
任务状态负责人截止
ALP-142支付流程重新设计In reviewJH9月24日
ALP-139整理新手引导邮件序列In progressSY9月25日
ALP-131确定 Search API 响应规范BlockedMK9月26日
ALP-128冲刺 12 复盘文档TodoJH9月29日
ALP-124检查工作区权限策略TodoSY10月2日
Problem
是不是每次都要重新说明一遍？
在通用的对话式 AI 里，每开始一项新工作，往往都要重新交代项目的背景与结构、需求以及以往的决定。
传递上下文→提出请求→确认结果→请求修改→再次传递上下文REPEAT
对话很快，但项目越长，人来传递上下文、再把结果搬回工作里的活儿就越多。
Human carries the context
Project BackgroundRequirementsTech StackPrevious DecisionsCurrent TaskRelated DocumentsConstraints
AI AssistantGeneric LLM
“这个项目用的是 Next.js 16……”
“现有的认证结构是……”
“上次的决定是……”
“这次的任务要……”
Human carries the context
Project BackgroundRequirementsTech StackPrevious DecisionsCurrent TaskRelated DocumentsConstraints
AI AssistantGeneric LLM
“这个项目用的是 Next.js 16……”
“现有的认证结构是……”
“上次的决定是……”
“这次的任务要……”
不是 AI 慢，
而是向 AI 说明工作的过程在不断重复。The bottleneck is not always the model. Sometimes, it's the workflow around it.
PJT
在 PJT，项目本身就是上下文。
计划、Tech Spec、任务、文档、决定与工作结果，都连接在同一个项目里。
AI 代理基于需要的项目上下文开展工作，结果又回到任务与 Knowledge 中。
BEFORE · 每次由人传递
Project BackgroundRequirementsTech StackPrevious DecisionsCurrent TaskRelated DocumentsConstraints
Plan计划 · 3 个阶段PhaseMS 2 进行中Epic6 个Task24 个 · 未完成 9Tech Specv3 已确定Docs38Knowledge依据 112Decisions14History全部变更记录Agent Result执行日志 · 产出物
循环
PROJECT CONTEXT与项目相连的上下文
AI AGENT基于上下文执行
WORK以任务为单位的工作
RESULT产出物 · 验证
KNOWLEDGE依据与决定的记录
↺ 结果重新成为上下文
减少说明的时间，
把精力放回真正的工作上。
不是在使用 AI，而是和 AI 一起工作。
人与 AI 理解同一个项目，在同一条工作流里各自承担角色。
人决定方向，AI 代理执行工作，结果又成为项目的上下文。
Agent
HumanYR永录
批准了引入 Passkey 认证的方向Decision · 9月18日
请求评审 Tech Spec v2Review · 9月19日
确定了 3DS 认证的范围Direction · 9月20日
DirectionDecisionReviewApproval
Shared Project ContextProject Alpha
PlanTech SpecTasksDocsKnowledgeDecisionsActivityHistory
人和代理看到的是同一份信息。
AI AgentIdle
Understanding context
Planning
Working
Verifying
Completed
ALP-128Implement Passkey Authentication
AnalyzePlanExecuteVerify
Work · ResultWaiting
Implement Passkey Authentication
变更文件7
测试Passed
评审已申请
Knowledge
实现笔记 · Passkey 认证流程
它会进入 Project Alpha 的上下文，下一项工作中人与代理都会参考。
重新成为上下文项目越往前推进，上下文就越厚。
真实协作场景 · Tech Spec 变更之后
- Human批准 Tech Spec 变更
- PJT ContextTech Spec Updated
- AgentAnalyzing affected tasks
- AgentTASK-128 implementation startedWorking
- ResultImplementation CompletedTests 42/42 passed · 3 files changed
- HumanReview Requested
- KnowledgeDecision / Result Stored
Human decides.Agent executes.PJT keeps the context connected.
HumanContextAgentWorkKnowledgeContext
Personalization
Quiet by default.
Rich when you need it.
Workspace Theme 不是给画面上色的装饰，而是表达选择与状态的方式。背景和表面保持中性，只有选中的项目和主要操作才用颜色。
ApexStack/Project Alpha
搜索⌘K
Project Alpha
In progress新建任务概览任务时间线文档
进度68%
未完成任务24
本周到期6
文档38
ALP-142支付流程重新设计In reviewJH9月24日
ALP-139整理新手引导邮件序列TodoSY9月25日
Space
工作的单位不是项目，
而是 Space。
产品团队、运维团队、市场团队的节奏各不相同。Space 把这种差异变成结构，让每个团队只在自己的上下文里行动。
产品研发
Product Development · 项目 8 · 成员 12
预订站点改版72%进行
移动应用 v2.138%进行
支付模块更换12%计划
需求抽取14 条 · 完成
IA 草案生成5 页 · 完成
设计系统32 个令牌 · 进行中
预订流程需求 v312 分钟前
设计系统令牌3 小时前
6 月发布说明昨天
取消政策的解读AI 依据 8 条
竞品分析依据 12 条
无障碍检查清单依据 5 条
一
二
三MS 2
四
五发布
金金度贤完成 3 个任务
朴朴瑞妍撰写 2 篇文档
李李俊豪合并 4 个 PR
DHSYJHMSMJ+7
9 个组件Active Projects · Recent Documents · Knowledge · Assets · AI Activity · Calendar · Team Activity · Members · Timeline
Space 范围展示的所有数据都限定在当前 Space 内。
AI 活动记录谁执行了哪次 AI 操作，在仪表板上一眼可见。
搜索 Space
产品研发Product Development
Active Projects
Recent Documents
Knowledge
Assets
AI Activity
Calendar
图标 · 颜色 · 说明用眼睛分辨 Space，而不是靠名字去找。
模板 · 成员 · 项目数进去之前就知道规模和性质。
最近动态在切换器里先看到最后发生了什么。
SYSTEM TEMPLATES
包含模块 · 6
OverviewProjectsKnowledgeDocumentsAssetsCalendarMembersOperations
Product Development · 产品研发 — 从需求到冲刺再到发布
创建之前先用预览确认会包含哪些模块。
Knowledge · Documents · Assets
知识、产出物与资源的角色，
我们分得很清楚。
都堆在同一堆“文件”里，谁都不知道该把东西放到哪儿。我们把三个角色分开，只让它们彼此相连。
Documents最终产出物
已经达成一致的成果：方案、规格书、报告。版本被固定下来，用于共享与审批。
- 版本 · 审批记录
- 面向外部共享
- 已确定的状态
AssetsWorkspace 资源
图片、标志、图标、视频、文件、模板。在任何项目和文档中都能引用的公共资源。
- 连接到项目 · 文档
- 按类型预览
- 模板可复用
Enterprise Security
安全不是一个设置页，
而是一块仪表板。
我们把采购评审会问到的项目做成了界面：查看状态、保管密钥、按层级授予权限、留下变更记录。
86
Security Score还剩 3 项建议处理
强制 MFASSO 就绪审计日志 90 天
EncryptionAES-256 · 传输使用 TLS 1.3正常
MFA24 位成员中 21 位已启用需要处理
Active Sessions9 个会话 · 3 台设备正常
Connected AppsSlack · GitHub · Figma正常
Login History近 30 天异常 0 次正常
API Keys6 个 · 1 个即将到期需要处理
Production DBPasswordInfra2 小时前
Stripe Live KeyAPI KeyBilling昨天
GitHub Actions TokenTokenPlatform3 天前
deploy@apexstackSSH KeyInfra一周前
*.pjt.aiCertificateInfra还有 42 天到期
prod.envEnv VariablesPlatform5 小时前
类似 1Password 的表格。类型 · 归属 · 最近使用，一行看全。
WorkspaceAdmin直接指定
Space · 产品研发Editor直接指定
ProjectsEditor继承
KnowledgeEditor继承
DocumentsViewer直接指定
AssetsEditor继承
MembersViewer直接指定
从上层继承权限，只在需要的地方收紧。例外会保留标记。
10:24金度贤变更 Space 权限产品研发 · Documents → Viewer
09:51李俊豪签发 API 密钥pjt-mcp-prod
09:12Sarah Chen查看 Vault 条目Stripe Live Key
昨天 09:00系统MFA 未设置提醒3 位成员
AES-256 静态加密TLS 1.3 传输SSO · SCIM (Business)审计日志保留 90 天不用于模型训练
PJT 并不止于管理项目和任务。
它把计划、Tech Spec、任务、Documents、Knowledge 与工作结果连接成同一个项目上下文，让人与 AI 代理能在同一条工作流里协作。
在通用的对话式 AI 里，每次提出请求，往往都要由使用者重新交代项目背景、需求和以往的决定。
PJT 的设计让 AI 代理能基于项目内已连接的工作上下文开展工作，重点在于减少重复说明和工作切换。
AI 代理可以基于项目上下文和分配到的工作，完成分析、计划、执行、验证等任务。
人负责决定方向并审阅结果，代理的工作结果又会回到项目的工作与知识中。
不会。
PJT 追求的不是用 AI 取代人，而是人与 AI 各自承担角色、一起工作的环境。
人负责方向、判断、优先级与审批，AI 代理协助完成必要工作的分析与执行。
可以。不只是新项目，已有的项目也能迁入 PJT 的工作结构并继续管理。
把项目原有的计划和工作信息接入 PJT 之后，就能扩展到任务、Documents、Knowledge 以及 AI 代理的工作流。
可以。
在个人项目中也能管理项目、任务、Documents 与 Knowledge，并与 AI 代理一起推进工作。
团队变大之后，可以把同样的项目和工作上下文分享给成员一起协作。
客户数据不会用于 AI 训练。数据静态存储使用 AES-256 加密，传输使用 TLS 1.3，访问记录会留在审计日志中。
可以。PJT 可在网页上使用，也可以通过 Desktop App 在独立的工作空间中使用。
你可以选择更适合自己工作环境的方式。