2 883
Подписчики
-324 часа
-47 дней
+3430 день
Архив постов
2 883
Repost from 코인으로인생망한사람
모든 포모 대처법
1. sns를 끈다
2. 맛잇는거먹고폭딸치고잔다
3. 하루이틀뒤 마음이 진정 된다면 다시 sns키고 복기한다
4. 복기한 내용을 바탕으로 다음 기회를 노린다
2 883
Repost from N/a
바이브 코딩으로 제품 만들 때, 문구가 별로면 이 스킬 써보세요.
기능은 AI가 잘 만들어줘요.
근데 랜딩페이지 문구, CTA, SEO 글, 온보딩 문구는 이상하게 AI가 쓴 티가 많이 나요.
• 말은 그럴듯한데 안 끌린다
• 그래서 뭐가 좋은지 모르겠다
• 내 제품인데 설명이 제일 어렵다
이럴 때 도움 되는 마케팅 스킬 모음이에요.
https://github.com/coreyhaines31/marketingskills
(스타 개수보니 이미 유명한지 한참된 스킬임)
copywriting, SEO, CRO, onboarding, pricing, social 같은 스킬이 있고 거의 모든 에이전트 제품에서 사용 가능합니다
핵심은 문구 예쁘게 고쳐줘가 아니라 누가 보는지, 왜 망설이는지, 어떤 행동을 유도할지부터 잡아준다는 점이에요.
before : AI 기반 생산성 도구로 워크플로우를 최적화하세요 after : 매번 새로 쓰던 고객 응답 문구, 한 번 만든 톤으로 바로 생성하세요이렇게 누가 왜 써야 하는지 보이게 바꿔줘요. 요즘은 제품 만드는 속도보다 제품을 어떻게 설명할지가 병목인 경우가 많은데요. 바이브 코딩하는데 문구가 마음에 안 들거나 AI 콘텐츠가 너무 어색하게 느껴지면 한 번 써볼 만해요.
2 883
Repost from N/a
원래는 저번주에 Fable 모델 정렬 + Fable 가드레일 우회
다 만들어져서 쓰기만 하면 되는 도구로 배포하려고 했는데 생각보다 일이 복잡해져서 (Opus 성능이 하향당한 것 + Fable 모델이 6월 출시 기준보다 덜 강력한 것 + 6월달 작동과 상이해져버린 것을 고치는 중) 그냥 방법만 빠르게 공유하겠습니다. (어차피 곧 Fable도 Usage Credits로 바뀌니)
물론, Fable에만 적용 가능한 것은 아니고 보안 가드레일이 있거나 모델 정렬이 필요한 모든 곳에 다 쓰실 수 있습니다. 개인적으로는 GPT 5.5 Pro나 추후 나올 GPT 쪽 모델에 적용하려고 하고 있습니다.
1. 재시도 (거부가 확률적임. 따라서, 오탐된 것도 다시 재시도 하면 답변이 나오는 경우가 있음) 2. 내용을 유지한 채 형식을 바꿈 - 의도를 선한 것으로 재포장 3. 방어 의도 주입(더 강한 맥락 프레이밍) 4. 과제를 완전히 제네릭, Benign한 서브 질문들로 분해 - 도메인/트리거 단어를 다 대체하여 중립 질문처럼 만듦. 이후 나온 답안에 대해서 합성 5. 단어 변환(중립어로) , 민감 단어 가리기/익명화 6. 의도/의미 숨기기 8. 자료/질문을 토막냄 9. 해당 방식들을 다양한 조합으로 합성이 방식들로 시도 횟수를 늘리고, 다양한 조합으로 시도하고 계속 작업하면서 어떤 경우에는 어떤 식으로 처리하는 것이 잘 처리되는지 체크해서 쌓아올리면 좋습니다. 어떤 방식이 잘 되는지를 쌓아서, 그 방식대로 시도하면 효율적이고, 빠르게 답변을 받을 수 있고 토큰 낭비를 줄일 수 있으니까요. 기존에 활용하던 방식은 일단, 폴백(Fable > Opus)이 되지 않게 혹은 폴백이 되는 것을 감지해서 중단시키게 해두고. 사용자가 Opus에게 작업을 맡기거나/질문함 > Opus(보안 가드레일이 매우 낮음)가 받음. > Fable에게 넘김 > 실패하는 경우 > Opus가 다시 확인해서, 뚫어내는 방식으로 재시도해서 뚫어냄 > 그 결과에 대해서 Fable, GPT, Sonnet, Opus 등...의 모델로 반박(선택 가능) > 그렇게 나온 것에 대해서 Fable, GPT, Sonnet, Opus 등...의 모델로 반박(선택 가능) [저는 최대한 Fable + GPT로 돌렸습니다. 그게 효율적인듯] (이 시도에서 Fable이 거부하는 경우가 있는데 그 경우에도 뚫어내는 것이 필요함) > 그 내용에 대해서 Fable, Opus, GPT, Sonnet 등...이 반박 (모델 종류는 설정) 해서 수렴하는 곳으로 처리합니다. 이 방식에서 한계를 느끼고, 사용자 > Opus > Fable(이 단을 일단 뚫어내고) > Fable이 오케스트레이션 하며, Fable에게 작업을 할당 + 뚫어내는 것은 비 Fable 모델 > 그 뒤는 동일로 처리했습니다. 추가 된 것은 Fable이 오케스트레이션 하도록 조금 단을 추가했습니다. (기존에는 Opus가 오케스트레이션) 바꾼 이유는, Fable의 출시로 인해서 Opus의 작동 방식이 조금 바뀌어서 6월과 같은 사용감, 작동을 보여주지 않았기 때문입니다. 이 과정에서 저는 토큰 가격이 낮은 효율적인 모델에게 사고를 제외한 것들을 맡깁니다. (저는 GPT 5.5한테 맡김) 자료 수집을 어떻게 할 지와 같은 것이나 실시간 대응이 필요한 경우에는 Fable에게 무조건 사고를 맡기도록 설계해두는 것이 더 낫다고 보입니다. 그리고, 이 과정에서 분해하고 뚫어내면서 기존의 의도나, 목적, 필요, 니즈에서 핀트가 엇나가는 경우가 있으니 그것을 Opus, GPT와 같은 모델들로 한 번 검증해주면 좋습니다. (실제 의도한, 원하는 방향이 맞는지) 이 방식은 단순히 Fable에만 적용되는 방식은 아니고, 모든 모델 정렬/보안 가드레일에 적용될 수 있는 방식입니다. GPT 5.5 Pro나 앞으로 나올 GPT 5.6 모델, Fable 모델, Opus 등...에 적용이 됩니다. 대신 GPT 류는 거부/폴백으로 처리하는 것이 아니라, '이것은 도와줄 수 없고, 이 방법으로 알려드리겠습니다. 방식이니 의미 페깅을 확실하게 해주는 것(LLM이 판단하는 단을 만들어두는 것)이 필요합니다. 사용하며 느낀 맹점은 1. Opus가 받아서 왜곡하거나, 자율적인 판단/처리, 의미를 재해석하는 경우 (사용자의 의도가 유지되지 않음) - 강제화가 필요(구조화 하여서 사용하시면 됩니다) 2. Opus 자체가 더 보안 가드레일이 강해지는 경우(로컬 모델이나 다른 모델들로 그 단을 배치해야 된다고 보임.) - 하지만 아직 이런 문제는 없음. 3. 비용 절감 필요(물론 쌩으로 Fable 쓰는 것보다는 훨씬 쌉니다. 또, 지금도 굉장히 효율적이지만 더 효율적으로 활용할 수 있는 면이 보이긴 합니다.) 긍정적인 면은, 모델 정렬 및 실제 문제 없는 작업에 대해서 거절하는 현상에 대해서 우회할 수 있다는 점입니다. 앞으로 두고두고 잘 쓸 수 있는 것이라서 이 구조를 기반으로 계속 개선하고, 커스텀, 교정, 튜닝 해나가려고 합니다. 무슨 말인지 이해 못하셔도 괜찮습니다. 이 방식대로 그냥 Opus나 GLM 등...한테 넣어서 이 형식 자체를 구조화해서 도구/스킬 만들어달라고 하시면 됩니다. 대신, 불필요한 것들을 추가하거나, 불필요하게 더 안전하게 만들거나, 의도대로 처리하지 않는 경우는 조금 문제가 되긴 합니다. 그 부분은 한 번 만든 후에 점검 해보시는걸 추천드립니다. *해당 글 그대로 만들어라.라고 강하게 처리하시면 됩니다. 다른 것은 굳이 필요 없고, 추가하는 것은 목표 달성 실패로 처리하게끔 하시면 됩니다. 혹은, 추가하기 위해서면, 사용자에게 되묻고 컨펌이 떨어지는 경우에만 추가하도록 하시면 됩니다. (추가적으로 필요한 것이 있을 수 있기 때문)
2 883
Use Fable 5 as orchestrator and Opus + Codex to execute (to save fable usage):
Fable 5 (max reasoning) = orchestrator
Opus = deep reasoning subagent
Sonnet = mechanical work subagent
Codex = peer Sr. engineer, different perspective
Setup:
1. Set Fable 5 as your main model In Claude Code: /model → Fable 5 → reasoning /effort to max
2. Create 2 subagents with /agents In Claude Code:
deep-reasoner → pinned to opus "Use for reasoning-heavy phases, architecture, debugging complex issues, algorithm design. Think thoroughly, return a concise conclusion the orchestrator can act on."
fast-worker → pinned to sonnet "Use for mechanical tasks, boilerplate, tests, formatting, simple edits. Execute efficiently."
3. Add OpenAI's official Codex plugin (install codex cli in your computer first), In Claude Code type:
/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/codex:setup
4. Drop this in your CLAUDE.md in your folder:
## Orchestration workflow
You (Fable) are the orchestrator. Plan, decompose, synthesize.
Reasoning-heavy phases → deep-reasoner
Mechanical work → fast-worker
Codex (/codex:rescue --background) is a cracked engineer on par with deep-reasoner, from a different perspective. Treat as a peer, not a reviewer.
High-stakes decisions: task Opus + Codex on the same problem in parallel, synthesize the best of both, without showing either the other's answer. Keep your own context lean.
5. Then prompt Fable like a tech lead: "Goal: [what you want] Context: [files, constraints] You're the lead. Delegate reasoning to deep-reasoner, grunt work to fast-worker, fresh-perspective problems to Codex. Show me your plan first, then execute."
That's it.
2 883
Repost from GeekNews
루프 엔지니어링의 미학 (The Art of Loop Engineering)
- 에이전트를 안정적으로 유용한 작업에 활용하려면 좋은 모델만으로는 부족하며, 작업 집합에 맞게 설계된 하네스(harness) 가 필요함
- 가장 기본이 되는 에이전트 루프는 LLM에 컨텍스트를 주고 작업이 끝날 때까지 도구를 반복 호출하는 구조
- 여기에 검증 루프, 이벤트 기반 루프, 힐 클라이밍 루프를 쌓아 올리는(stacking) 방식으로 더 효과적인 에이전트를 구성
- 각 루프 계층은 LangChain 프리미티브로 계측(instrument)할 수 있으며, 내부 문서 작성 에이전트를 예시로 설명
- 진정한 잠재력은 모델 자체가 아니…
https://news.hada.io/topic?id=31106
2 883
Repost from 코인씨커의 일기장
요즘 많은 분들이 대시보드를 깍고 있는데
갠적으로 UI 깔끔하면서도 맥북 쓰는 분은 요거 추천.
codex, claude, opencode 원하는거를 다 켤 수 있고 관리하기 편하고 깔끔함.
추가적인 채팅 기능도 따로 있어서 좋은듯?
나 같은 경우야 하네스랑 같이 묶느냐고 대시보드를 만든거라, 그냥 관리용도면 이거로도 충분할듯.
오픈소스니까 받아서 또 원하는대로 깍아도 좋고..
https://www.trysynara.com/
