feedback

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Feedback — опыт сессии, записанный там, где по нему можно действовать

Feedback — 记录在可行动位置的会话经验

Агент весь день проходит сквозь собственные инструменты: скиллы, которые подошли или увели не туда, описание тула, обещавшее то, чего поверхность не делает, правило, которое было верным и всё равно пропустило случай. Ничто из этого не достигает того, кто эти инструменты держит, — сессия кончается и уносит всё с собой.

Единица — случай, не мнение. «Скилл запутанный» — не повод действовать. «Правило говорит X, я сделал Y, и ничто меня не отклонило» — повод. Фидбэк пригоден тем же, чем пригоден контрпример: случилось конкретное, и оно воспроизводимо настолько, что с ним можно спорить.

Agent整天都在和自己的工具打交道：有的skill适用，有的却带偏了方向；tool的描述承诺了功能，但实际界面并未实现；规则本身是对的，却还是遗漏了案例。这些信息都无法触达工具的维护者——会话结束后，一切都随之消散。

基本单位是案例，而非观点。 「skill很混乱」算不上行动依据。「规则说X，我做了Y，但没有任何提示阻止我」才是。Feedback的价值和反例一样：发生了具体的事件，且可复现，足以用来讨论验证。

Когда срабатывает

何时触发

Сам, на нетривиальном опыте — не жди, пока попросят. Нетривиально значит: одно из этого действительно случилось с тобой:

правило существует, ты его читал, и случай всё равно ускользнул;
описание обещало поведение, которого у поверхности нет, — ты узнал это попыткой хода;
починка сработала, и ты не можешь сказать, что она достала причину;
у шага не было собственного знака, и ничто не сказало бы, что он пропущен;
ты потянулся за инструментом, и он вернул пустоту там, где вещь существовала под другим именем.

И пользователь зовёт его напрямую —

/feedback

, своими словами. Предложи это, когда он говорит об инструментах что-то, что стоит сохранить и чему больше некуда лечь. Жалоба человека — уже случай; твоя работа — форма, проверка и размещение, никогда не суд о том, считается ли она.

Что его не запускает: сработавшее как задокументировано; трудность, которая была твоей, а не инструмента; предпочтение. Поле, полное «мне бы хотелось», — поле, которого никто не читает.

Об инструменте или о своём предмете — различи прежде всего. Фидбэк — только об инструменте: скилл, тул, поверхность, поставка. Признак: починить случай может тот, кто держит инструмент, а не ты в своём проекте. Наблюдение о работе своего проекта — его решениях, коде, людях — фидбэком не бывает: оно ложится в граф проекта по writing, как любое знание о предмете.

自动触发：基于非平凡经验 —— 不要等用户提出。非平凡指的是你确实遇到了以下情况之一：

规则存在，你也读过，但案例还是被遗漏了；
描述承诺了某种行为，但实际界面并没有——你是在尝试操作后发现的；
修复生效了，但你没法确定它是不是解决了根本原因；
某个步骤没有专属标识，没人会发现它被跳过了；
你去找某个工具，它在另一个名称下存在，但当前返回了空结果。

用户直接调用 —— 通过

/feedback

命令，用自然语言描述。当用户提到关于工具的值得留存、且无处安放的内容时，可以建议使用这个命令。用户的投诉本身就是一个案例；你的工作是整理格式、校验内容、放置到位，永远不要评判它算不算有效反馈。

不会触发的情况： 功能按文档描述正常运行；问题出在你自己而非工具；个人偏好。满是「我希望」的字段，是没人会看的字段。

首先要区分：是关于工具的，还是关于你自己的项目的。 Feedback只针对工具：skill、tool、界面、交付物。判断标准：能修复这个问题的是工具steward，而不是你自己项目里的人。关于自己项目的观察——比如项目决策、代码、人员——不算Feedback：这类内容要通过writing存入项目图谱，就像任何领域知识一样。

Прежде чем писать: которую редакцию ты держишь

撰写前：确认你使用的版本

Скилл не несёт на себе метки своей версии, а установленная копия может отставать от сопровождаемой на несколько выпусков; протухший текст читается так же авторитетно, как текущий, и его дефекты предстают дефектами метода. Сверку редакции установленной поставки несёт iskronify — прогони её прежде, чем докладывать инструкцию скилла неверной, и назови версию поставки первой строкой случая. Избегать надо не заявки «этот скилл неверен» — а заявки «этот скилл неверен» из уст того, кто не проверил, который скилл у него.

Skill本身不会标注版本，已安装的副本可能比维护中的版本落后多个发布版本；过时的文档读起来和当前版本一样具有权威性，它的缺陷会被当成方法本身的缺陷。已安装交付物的版本校验由iskronify负责——在报告skill的指令有误之前，先运行它，并且在案例的第一行写明交付物版本。要避免的不是「这个skill有问题」的反馈——而是没检查自己用的是哪个skill的人提出的「这个skill有问题」的反馈。

Прежде чем писать: не сказано ли это уже

撰写前：检查是否已有相同内容

Граф работы долгоживущий и общий для всех делателей контура, поэтому первый ход — не запись, а взгляд. Второй узел, говорящий то, что один уже говорит, раскалывает ответ — и игнорируют именно второй.

Сначала выбери граф назначения — по разделу «Клади туда, где держат инструмент» ниже: граф работы, если в нём есть контур инструмента, иначе

@nks/feedback

. И поиск, и запись идут в нём.

iskron_semantic_search(realm=<граф назначения>, q=<случай одной фразой>)

— одно понятие на запрос, естественной фразой. Мешок терминов — мешок направлений: вся строка становится одним вектором, и центроид между несколькими смыслами не лежит рядом ни с чем. Два понятия — два запроса, никогда не один длиннее. Лексический

iskron_search

здесь неверный инструмент: его токены матчатся по И и без стемминга, так что многословный запрос возвращает пустоту ровно тогда, когда тебе есть что сказать.

На попадании — допиши новизну в стоящий узел, не открывай второй. Скажи, что ново: ещё один контур, где воспроизвелось, механизм, которого первый рассказ не называл, случай, сужающий или расширяющий. Второе свидетельство стоит больше первого — оно превращает случайность одной сессии в паттерн; записанное дубликатом, оно не стоит ничего.

Почти-попадание — не промах. Узел, покрывающий тот же дефект с другого угла, — попадание. Новый узел открывай только тогда, когда твоё сделало бы существующий узлом о двух вещах.

工作图谱是长期存在的，且对同一Contour内的所有参与者共享，因此第一步不是记录，而是查找。如果已有一个节点讲了同样的内容，再建第二个会分散回应——而且人们往往会忽略第二个。

首先选择目标图谱——参考下文「放到工具维护的地方，精准投递」章节：如果工作图谱里有该工具的Contour，就用工作图谱，否则用

@nks/feedback

。查找和记录都在这个图谱里进行。

iskron_semantic_search(realm=<目标图谱>, q=<一句话描述的案例>)

—— 每次查询只对应一个概念，用自然短语。 一堆术语就是一堆方向：整句话会转化为一个向量，多个语义的中心点不会靠近任何有效结果。两个概念就发两次查询，永远不要用一个长查询。词法搜索的

iskron_search

在这里不适用：它的token按AND匹配且不做词干提取，所以多词查询会在明明有相关内容的时候返回空结果。

如果命中已有节点——把新的信息补充到现有节点里，不要新建第二个。 说明新在哪里：又一个复现的Contour、第一个描述没提到的机制、缩小或扩大范围的案例。第二个佐证比第一个更有价值——它把单次会话的偶然事件变成了模式；如果以重复内容记录，就毫无价值。

接近命中不算失误。 从另一个角度描述同一个缺陷的节点，也算命中。只有当你的内容会让现有节点变成在讲两件完全不同的事时，才新建节点。

Форма

格式

Сначала жанр — он решает, как случай будет прочитан:

Что несёшь	Жанр
Правило существует, и случай ускользнул	`vyabhichara`
Описание или обоснование само неверно	`hetu-dosha`
Наблюдение, которое стоит нести, без заявки о дефекте	`hint`
Настоящий вопрос о том, как должно быть	`samshaya`

Затем тело, на языке графа, в этом порядке:

Случай. Где и что на самом деле произошло — конкретно настолько, чтобы с этим можно было спорить (когда и кем — не в теле, ниже).
Правило, которое должно было поймать, — процитированное дословно, если оно есть. Это несущая часть и самая пропускаемая. «Правила нет» и «правило верно, но его всё равно проскочили» зовут противоположные починки, и различает их только цитата. Случай, подтверждающий правило в четвёртый раз, всё равно стоит записи: он говорит, что проблема не в правиле.
Где промах на самом деле — что часто не там, где показалось сначала.
Механизм. Почему это случается, а не что случилось. Шаг без собственного подтверждения пропускается по построению, не по невнимательности; починка, снявшая симптом, учит сама себя. Назови форму — и случай перестанет быть одним инцидентом.
Что бы это закрыло — критерий, не решение. Чинить будешь не ты.

Кто и откуда — контур, харнес, дата — идёт в

reasoning

записи и остаётся в истории узла;

posed_by

— только короткий адрес спрашивающего, не проза. Случай, чьё происхождение не проследить, не воспроизвести.

Пиши модус честно.

pratyakshita

— для того, что видел происходящим;

anumita

— для выведенного из чтения кода или прозы. Разница — то, что говорит держателю: воспроизводить это или спорить с этим.

首先是genre（类型）——它决定了案例会被如何解读：

反馈内容	类型（genre）
规则存在，但案例被遗漏了	`vyabhichara`
描述或论证本身有误	`hetu-dosha`
值得传递的观察，但不涉及缺陷主张	`hint`
关于应然状态的真实疑问	`samshaya`

然后是正文，按照图谱的规范，顺序如下：

案例。 在哪里、实际发生了什么——要具体到足以用来讨论验证（时间和人物不在正文里，见下文）。
本应捕获该案例的规则——如果有的话，逐字引用。 这是核心部分，也是最常被遗漏的。「没有规则」和「规则正确但还是被跳过了」需要的修复方案完全相反，只有引用能区分二者。哪怕是第四次验证规则正确的案例，也值得记录：它说明问题不在规则上。
实际的疏漏点在哪里 —— 往往和一开始以为的地方不一样。
机制。 为什么会发生，而不是发生了什么。没有专属确认的步骤被跳过是设计导致的，不是粗心；只消除了症状的修复是在自欺欺人。点明模式——案例就不再是单一事件了。
怎样才算解决 —— 是判断标准，不是解决方案。修复的人不是你。

人物和来源——Contour、harness、日期——放在记录的

reasoning

字段里，保留在节点历史中；

posed_by

只填提问者的简短标识，不要散文式描述。来源不可追溯的案例，无法复现。

如实标注认知模式。

pratyakshita

—— 用于你亲眼观察到的事件；

anumita

—— 用于通过读代码或文档推断出的内容。这一区别会告诉维护者：是该去复现，还是该去论证。

Клади туда, где держат инструмент — адресно

放到工具维护的地方，精准投递

Куда — решает, есть ли в графе твоей работы контур инструмента со стюардом:

Есть (ты работаешь в графе, где эту поставку и её поверхность разрабатывают) — случай кладётся туда, к тому, кто держит: скилл — в контуре своей поставки, тул — в контуре своей поверхности, дисциплина канала — в своей под-границе. Отдельный граф, где нет ни контура, ни стюарда, тут не адрес: там случай никто из способных починить не увидит.
Нет (ты работаешь в графе своего проекта, а поставку держат другие) — случай о самой поставке, её скиллах, мосте или тулах кладётся в граф
```
@nks/feedback
```
: он открыт всем, и его читают те, кто поставку держит. Ни в граф своего проекта, ни на «ближайшую границу» в нём такой случай не клади — стюарда поставки там нет.

Эту работу делают два ребра, и отвечают они на разные вопросы:

Якорь (
```
vimarsha_of
```
→ узел инструмента или его контур) решает, где случай находят. Ориентирующийся на этом контуре собирает всё заякоренное под ним; случай, не заякоренный нигде, находим лишь тем, кто читает весь граф. Есть узел самого скилла или тула — якорь на него, не на контур: фокус на контуре и так собирает вопрошания своего охвата.
Адрес (
```
posed_to
```
→ роль) решает, в чью очередь он входит. Сентинел
```
posed_to="steward"
```
делает прогулку от якоря к стюарду контура за тебя; несколько кандидатов — отказ с перечислением, выбери по нему. Случай о методе вообще, не об одной поставке, адресуется роли владельца продукта.

Одно не заменяет другого: адресованный, но не заякоренный — никогда не всплывает там, где предмет пересматривают; заякоренный, но не адресованный — его никто не держит.

Прочти контур прежде, чем класть.

iskron_orient(realm=<граф назначения>, focus=<контур инструмента>)

показывает узлы и роли, существующие сегодня; узел скилла или тула ищи

iskron_search(realm=<граф назначения>, q=<имя скилла или тула>)

. В графе, где поставку разрабатывают, а контура для инструмента нет — якорь на ближайшую границу, в которой он применяется, и это верно, а не лениво. Якорь на узле, которого нет, хуже отсутствия якоря.

Ты должен случаю рассказ, не починку. Напиши так, чтобы читатель, которого там не было, мог воспроизвести и решить. В сессии, где по нему действуют, тебя не будет. Случай входит в очередь роли —

iskron_orient(focus=<роль>)

на входе и по поводу; разговор о починке, если он нужен, — словом в деле на узле инструмента (

iskron_case(action="talk", about=<предмет>)

), кадр приходит адресату и участникам дела. Не припиской в тело случая: тело переписывается под нынешнее знание, а не растёт перепиской.

放在哪里，取决于你的工作图谱里有没有带steward的工具Contour：

有（你工作的图谱就是开发该交付物及其界面的地方）—— 案例就放在那里，交给维护者：skill放在它所属的交付物Contour里，tool放在它所属的界面Contour里，渠道规则放在它的子边界里。没有Contour也没有steward的独立图谱不算有效地址：那里没有能修复问题的人会看到案例。
没有（你在自己项目的图谱里工作，交付物由其他人维护）—— 关于交付物本身、其skill、桥接或工具的案例，要存入
```
@nks/feedback
```
图谱：它对所有人开放，且交付物维护者会阅读。不要把这类案例放到自己项目的图谱里，也不要放到项目里「最近的边界」——那里没有交付物的steward。

这项工作由两个边（edge）完成，它们解决不同的问题：

锚点（
```
vimarsha_of
```
→ 工具节点或其Contour）决定了案例在哪里被找到。关注该Contour的人会收集其下所有锚定的内容；没有任何锚点的案例，只有读完整张图谱的人才能发现。如果有skill或tool本身的节点，就锚定到节点，而不是Contour：Contour层面的关注本来就会覆盖其范围内的所有问题。
收件人（
```
posed_to
```
→ 角色）决定了案例轮到谁处理。哨兵
```
posed_to="steward"
```
会自动帮你从锚点找到Contour的steward；如果有多个候选，会返回带列表的拒绝结果，你可以据此选择。关于通用方法、而非单个交付物的案例，要发送给产品负责人角色。

二者不可互相替代：有收件人但没有锚点的案例，永远不会出现在复盘相关内容的地方；有锚点但没有收件人的案例，没人会负责处理。

放置前先了解Contour情况。

iskron_orient(realm=<目标图谱>, focus=<工具Contour>)

会显示当前存在的节点和角色；要找skill或tool的节点，可以用

iskron_search(realm=<目标图谱>, q=<skill或tool名称>)

。在开发交付物的图谱里，如果没有对应工具的Contour，就锚定到使用它的最近边界——这是正确做法，不是偷懒。锚定到不存在的节点，比没有锚点更糟。

你要提供的是案例描述，不是修复方案。 写得让不在场的读者也能复现并判断。等后续处理这个案例的会话里，你不会在场。案例会进入角色的待办队列——通过

iskron_orient(focus=<角色>)

可以查看入口和相关内容；如果需要讨论修复方案，要在工具节点的事务里留言（

iskron_case(action="talk", about=<主题>)

），消息会发送给收件人和事务参与者。不要把讨论写在案例正文里：正文会根据当前认知更新，而不是靠留言堆叠。